Re: The eternal uid issue

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3727 bytes --]

On Jul 23 13:35, D. Boland wrote:
> Corinna Vinschen wrote:
> > Not in relation to the uid.  In contrast to Linux we don't have the one
> > single root user.  We have potentially endless numbers of them, and one
> > of them, not necessarily SYSTEM, is used to run the service.  Keep in
> > mind that there may also be company policy in place which disallows
> > installing services under specific accounts unless absolutely necessary.
> > 
> > Therefore, while we mostly strive to make Cygwin accommodate user
> > space, we're not able to do it related to the root uid.
> 
> Thanks for your lengthly and detailed answer. I appreciate that. But
> don't you think upstream maintainers will raise at least one eyebrow
> if we propose code that makes any user who starts the program the
> root/admin user?  You suggest only those who are in the admin group.
> But that will soon be any service that starts up.

You're getting this wrong.  Cygwin is not the OS.  We do not make
every user an admin since we're in no position to do that.  We can't
give the user any more rights the OS is already giving the user.

The idea of such a test is to make the test independent of the actual
uid.  There are two cases.  One is to check if the user has admin
rights to perform certain actions, the other is to check if a file
ownership is safe.  A safe ownership is one where the file belongs
to the user running the service.  On Linux or BSD systems that's
usually the root user, in our case it's some arbitrary user account.
The check is basically the same.

> It actually is my solution to running Sendmail: create the Sendmail
> user, called 'smmsp' and make it an Administrator, so it can
> impersonate users on my system.  But I don't like my solution, because
> this would mean I have to create an admin-user for any Linux service
> that I install. So now my Cygwin setup would be crowded with highly
> privileged daemons, listening, waiting to get hacked.

That's what the cyg_server account is meant for.  It's the one account
which has the right to change the user context even when using method 1
from the setuid overview of the User's Guide.

Other services don't need this permissions, they just have to have
the right to create certain objects.  Cygserver is such a service,
for instance.  It's perfectly fine for cygserver to run under SYSTEM
or, FWIW, any other account with local administrative privileges.

> The more elegant solution would be to create only one secondary
> privileged user, let's call it 'root' ;-). Now Sendmail can start as
> root, switch to the totally *unprivileged* 'smmsp' user and receive
> mail.  Of course the real bonus is that these unprivileged users
> wouldn't need passwords, since they are impersonated, not logged on.
> These would consequently be *super-secure* users, because it is
> impossible to login with an empty password.

Same thing with cyg_server.

> Why is this related to the uid issue? I already tested the second
> solution. I found out that if I assign my 'root' user the '0' id in
> /etc/passwd, it actually works. I was delighted, because I could
> roll-back all these weird changes I put in the
> Sendmail/procmail/mail.local source to fix the getuid != 0 problem.

Yes, you can do that and it was always possible, but it requires
unnecessary user changes.  Also, passwd and group files are going
to become entirely superfluous at one point, and there's not a 
single account which is translated to uid 0 on the fly.  There
simply isn't one.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]