Requirement for sshd account since 4.4p1

[Corinna Vinschen]

Hi Darren,

On Oct 27 21:00, Darren Tucker wrote:
> On Fri, Oct 27, 2006 at 10:36:59AM +0200, Corinna Vinschen wrote:
> It's probably not just Solaris (any system where (seteuid(-1)) fails
> would be affected) but that's where it was reported.

Right, but this is for circumventing a bug in a small number of systems
while the effect is visible on all systems.  The fact that this is also
visible in sshd's which are not built with GSSAPI support at all is
another point.

> > This leaves behind users which have no admin access to their boxes and
> > just want to start a private sshd which allows to logon with their own
> > account.
> 
> That's one configuration I hadn't considered: running sshd entirely
> nonprivileged when the privsep account doesn't exist.
> 
> Maybe we could only load privsep_pw if we're running privileged?
> set*uid is not going to work if we're not.

Here's the problem:  Right now there's no way to figure out whether sshd
is running under a privileged account or not on Cygwin.  The problem is
that being privileged is bound to testing uid 0 in OpenSSH throughout.

I'm asking for some years now to replace the inflexible tests for uid 0
by a system specific function call along the lines of a

  bool privileged_user(uid)

This would be an enormous progress for systems which allow an arbitrary
number of privileged accounts, resp. for systems which are capable of
granting fine grained user privileges.  There's no reason why sshd
should run under uid 0 if there's a specific account on a system which
has the privilege to switch the user context.  I sent a patch once, back
in 2005, which we never discussed, unfortunately.

As a short term solution I would suggest that sshd doesn't exit
prematurely when it can't find the sshd account, but only later if it
finds that the sshd account is required for operation, like, for instance,
GSSAPI on Solaris, or if privilege separation is actually requested.

> > Looking into the source code it looks like this patch was never meant
> > to be something other than temporary:
> > 
> > struct passwd *
> > fakepw(void)
> 
> fakepw() has been there quite a while.  [...]

I wasn't referring to the name of the function, I was referring to the
fact that uid and gid get set twice, first to -1, then to the privsep_pw
value.

> Always having the privsep uid available is useful in other cases too
> (eg PAM, bug #1215).

I see, but not all systems use PAM either ;)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat