X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=vBfBnDxwKLpiTYI/68LHpuZu/GDIwOF0QFkzYJhuXKJiCpPhBXReh VTwEvMaLP7u6u20kN2WTymRXnJuj7NtK7vhNljv5nTkAKwUx4PtZSzvE3EU8Dj5N TqtFcs+zSXTR7nlZcqA6sySDaK+CYsXSDUudOfHVHVOqdbwrwLGU1I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=iIEm0v+IxyHelQwXVYYwmMaMpvA=; b=qSTfky42xzku++Y6YFs17L8dFJNC CPJ+LGVtlZGbpwy+GMimON4mJDPGFPrwDzDKPwTLwL1hL/4b+swS9OMfpZlOB/YJ Q7+5YAZjNiHTOmMb8v57KWTH6Rhfm89klky5dkR0NN3LBfaJHTx/Abr5zXERHqrq E2kzUdxZ8QcHqL8= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Date: Wed, 23 Jul 2014 17:23:57 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: The eternal uid issue Message-ID: <20140723152357.GA24446@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <53CF6CEC DOT 6D68E485 AT boland DOT nl> <20140723091409 DOT GH27005 AT calimero DOT vinschen DOT de> <53CF9E0F DOT F596FC60 AT boland DOT nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <53CF9E0F.F596FC60@boland.nl> User-Agent: Mutt/1.5.23 (2014-03-12) --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--