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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf