Mail Archives: cygwin/2014/07/23/11:24:34
--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
> >=20
> > Therefore, while we mostly strive to make Cygwin accommodate user
> > space, we're not able to do it related to the root uid.
>=20
> 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 !=3D 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=20
single account which is translated to uid 0 on the fly. There
simply isn't one.
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJTz9ONAAoJEPU2Bp2uRE+gXDgP/iNgsevIET7ut4hB8MAAAaPC
Col3pRfSTZ2zj6m4x6azpBo5qd/+hA7+y2TPzCR3uJo8JVU6lhsICwmNQkNFbhQb
z6Lo9SnmaG4rjwXG8jPCM5FBfNkcKZj+2gdPTacHuZd9js9uKAIOcoaBo/oTGZhz
dWa8rWIWAKN0oynl4SJYa9JNitx5jxOGrqW36nVfFFV1eNfXNYa8fDSSy4pv/AgR
JmOA0J0nPorej7Sgv8TatqrCWLcSmQoi3qoKol1SUgx50qHvPxPNsSaaxGZTo4d6
7YMeHYR+uIFIhi+GeCM5rTJip6baZfHzcwd06kI48X/Mh7u0BzCdFVZWRjahgrvi
+wUNtvwqwnMNOs+Up9QkaERfCPuC19VTWXNvq02bi7EfZ0eE6kV0Jk4KN3wFWPog
oCbOx4l2TRBgpFdvBagbIngW71J2awFsgShZcrr2FgqXRhazDOFUkAz2Cp9FIiuk
cVKRGCbUjVMdGEhLkNIHIZBfRH4w4NEc9Gy7S2i268CWCg+87d4FMycjtEisXAGp
qJjdZHsFwJ1QTKwS4D4WF8HxtXK1BIlpCPZi6NN9i1o6brSViTAraKykDysjwc7a
vmD5sI8aCS5DRE3fdDfWi3xwiDZmeIQxx0iuVeZBu20Igy/R5TlC+FRX1FUuy602
ESoKpLEXDoGBubzb1v0E
=W+2H
-----END PGP SIGNATURE-----
--3V7upXqbjpZ4EhLz--
- Raw text -