Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Dawes, Rogan (ZA - Johannesburg) (rdawesdeloitte.co.za)
Date: Mon Jul 08 2002 - 02:01:06 CDT
> I have one more specific question regarding daemons that take
> authentication, and switch to another uid. For something
> like a telnetd,
> or sshd that uses PAM.... in order to drop to a shell as the
> uid of the
> authenticated user, do they really need root? If you have the
> authentication information for the user, then you could call
> the system
> call equivalent of su, right? So the daemon is actually going after a
> privilege gain rather than a drop, because it starts as some
> account that
> can really only bind a special port.
Apart from the fact that "su" is setuid root in order to achieve this?
AFAIK, the ONLY way to become a different user under Unix is if root says
you can. Either via a suid root binary ("su"), or a service/daemon running
as root, e.g. telnet, sshd, rshd, etc. I suspect this is essentially the
same under NT/2000 as well.
It may be possible to code a limited "getprivs" program analogous to su,
that would return the "privileges" of the user credentials supplied.
Something like sshd's privsep code, where a limited root process simply
validates authentication credentials, and returns a "user owned" token that
allows them to do what they need to. e.g. a user owned fd, or pty, or
Well, it looks like I was talking rubbish. Even under sshd's privsep, the
privileged ssh daemon still forks a user owned process. I don't see a clean
interface to this that could be used by arbitrary processes.
It sounds to me like we want something like "sudo" for applications . . .