Ned Freed wrote:
>
>> But does that student have access to the root account on servers which
>> are part of the networking infrastructure? Who cares if Joe User
>> blows up his own config. on a PC that nobody else depends on but Joe?
>
> But if nobody has local access to these servers, why is it is
> necessary or
> useful for servers to run with root access in order to bind to these
> ports?
I think the discussion has reinforced and crystallized my personal
feeling on the subject:
- Services will have to start up listening to specific ports.
And in some cases they have to be able to reconfigure to listen on new ports
without a full restart. This makes the "use root to start then drop it"
approach problematic in some cases.
Whether
the port number is specified in an RFC, an SRV record or a config file
on a dozen other hosts is in fact irrelevant to the fact that they have
to start up knowing what port to listen to (unless they have write
access to SRV).
Yep.
- The "root gets to open ports < 1024" mechanism is harmful; there are
ports < 1024 that need to be opened by non-root processes, and ports >
1024 that need to be protected from "random programs".
Agreed.
- Conclusion 1: Hosts that care about separation of privileges need to
be able to specify access rights on ports as part of their configuration
- with "can be handed out to processes asking for a port" being one
particular kind of access right.
Yes, and there also needs to be flexibility as to what entities such access
rights are given to. Neither a "this UID has these rights" or "this executable
has these rights" are adequate in all cases, for example.
- Conclusion 2: There is no reason for standards to uphold the
distinction between <1024 and >1024 any more.
Well, there may be some marginal cases left, but if there are they are
certainly a minority taste now and their future fate seems certain. And we're
definitely at the point where the <1024 approach carries more cost than
benefit, so I agree that the time to drop the distinction in our processes is
now.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf