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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=T8RosMg3KDgRQI3t
	QpYfLbirGSMHyjzR34Oum/x4ts/xzNPU1aMgZksHESDZJ80Wb+FsOy+mXyrkhy9t
	aia0gLcgRfM1X0awSdconahKqsONcLjoSVZxqQA1sYvwPvjg+FsXUAQYIzF89G2s
	mLSfC9L6x+1ZmioC7A2HxdDcGM0=
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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=TrIlv7QsX9jyWTD433Ks6H
	d7l90=; b=rEYTCvHXHfLHpdilY/ZYGH6QCIGSrAblOTPg+6Llj1T7BYabRd+toh
	Cq41fi3zJjoN3OOHEDH1Pd07M7oAwBrnH/nP1yPMJW4OLKQk5sDvxRJjycWlMOND
	yeIGUfoXhuPwTg6W1jidfsfD3JjCegZu/gR+Z3lWQ8VR0AOIe+5Bs=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=3.4 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,MIME_BASE64_BLANKS,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO:	smtpback.ht-systems.ru
Date:	Thu, 24 Jul 2014 17:11:22 +0400
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<23917301.20140724171122@yandex.ru>
To:	"D. Boland" <daniel AT boland DOT nl>, cygwin AT cygwin DOT com
Subject:	Re: The eternal uid issue
In-Reply-To:	<53D0D316.F34DBB2B@boland.nl>
References:	<53CF6CEC DOT 6D68E485 AT boland DOT nl> <20140723091409 DOT GH27005 AT calimero DOT vinschen DOT de> <53CF9E0F DOT F596FC60 AT boland DOT nl> <1273556697 DOT 20140723200807 AT yandex DOT ru> <20140723162703 DOT GA3951 AT ednor DOT casa DOT cgf DOT cx> <53D0D316 DOT F34DBB2B AT boland DOT nl>
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id s6ODKbJR006773

Greetings, D. Boland!

> What I meant was that MS dicided to take away impersonation privileges from the
> SYSTEM user, without educating admins/developers about the new model or alternatives
> for SYSTEM.

There's no "model", there's "rights" or "capabilities", or "privileges".

> I searched the web extensively for an explanation on the newly imposed restriction.
> I didn't find one yet.

Because there's none.

> Only vague advice to not start services using the local System account:

> "Minimize the use of the Local System account on the site servers and site systems
> by not installing other services that use the Local System account. This ensures
> that other processes cannot take advantage of the enhanced privileges of the
> system’s computer account, accessing Configuration Manager 2007 files and data
> through those other systems."

Exactly that. What is unclear?

> So I have to assume that it was to enhance Windows security.

It's to enhance operating security of default installations. "Windows
security" as a "model" isn't changed in even slightest way.

> That is not far-fetched, since the SYSTEM "user" is totally unrestricted and
> not suited to be exposed directly to users from the outside.
> I also have to assume that what they mean by "not installing other services that use
> the Local System account" is to create a new user and running a service on behalf of
> it.

> Here's how they explain how to configure MS SQL Server (which uses impersonation),
> but without explaining the underlying security model for services:

> http://msdn.microsoft.com/en-us/library/ms143504.aspx

> The only reference I can find about the service security model are the terms
> "minimum rights" and "minimum privileges".

It's not "model" again. It's privilege separation.

> In Linux, the daemon security model is well-known and can be implemented by running
> as an 'unprivileged user'. Sendmail uses this idea extensively.

That's no different here. The point you miss is that in Windows you don't have
single "privileged user", which is just a long synonym for "root" in Linux
world. You have exactly "privileged users", as in "users that have privileges
above and beyond".

> Again, the only option I have at this moment is to run the Sendmail user (smmsp) as
> an Administrator, so it can do impersonation.

You contradicting yourself. Mere lines above you said your Linux user is
unprivileged, now you want to do impersonation. Which is only possible for
privileged user.

> But this does *not* constitute 'minimum privileges', nor does this make the
> Sendmail user run as an 'unprivileged user'.

That because... see above.

> The preferred solution is to only *start* Sendmail with a privileged user, let's say
> 'cyg_server'. Now Sendmail can switch to the 'smmsp' user and be running totally
> unprivileged, only having access to its mail queue directory.

Right.

> But after configuring Sendmail this way, it starts to complain about not having
> access permissions, because it detects it was not started with the root user (getuid
> != 0). 

Look, here you have a problem, that you don't want to understand it seems.
Checking for 'privileged user' is not the same as checking for 'uid == 0'.

> So, my original question was: can the Cygwin function 'getuid' be made to return '0'

No. A blatant and angry one. There's more systems, than Linux, and not all of
them employ same security model, nor their model can be closely approximated
to the one in Linux.

> if the program is running as the SYSTEM user? But because SYSTEM cannot be used
> anymore, Corinna suggests to use 'cyg_server' instead and put checks for
> administrator rights in the Sendmail source. 

> In my reply to her in this thread, I rephrased my question: can the Cygwin function
> 'getuid' be made to return '0'

"Can", "will" and "want" (or in our case "should") are three completely
different terms. The fact their areas intersect sometimes is a complete
coincidence.

> if the program is running as the SYSTEM user or is
> running with administrator rights?

No. If you want to do the right thing, do it right.


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 24.07.2014, <16:05>

Sorry for my terrible english...

- Raw text -