Re: Guidance needed on well known ports

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