Requirement for sshd account since 4.4p1

[Damien Miller]

On Fri, 27 Oct 2006, Corinna Vinschen wrote:

> 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.

The alternative of adding yet another platform-specific code path is
exactly what we are trying to get away from.

> 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.

I don't think it makes sense to have a sshd that fails at random times
once it has successfully started. Better to be clear at the beginning.

> > > 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.

That is just some dead code (deleted in HEAD), I don't get how this
could be construed as being "temporary".

-d