This is the mail archive of the
mailing list for the Cygwin project.
Re: The eternal uid issue
- From: "D. Boland" <daniel at boland dot nl>
- To: cygwin at cygwin dot com
- Date: Thu, 24 Jul 2014 11:34:14 +0200
- Subject: Re: The eternal uid issue
- Authentication-results: sourceware.org; auth=none
- 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>
Thanks for your reply.
Christopher Faylor wrote:
> On Wed, Jul 23, 2014 at 08:08:07PM +0400, Andrey Repin wrote:
> >Greetings, D. Boland!
> >> Cygwin security will be done for in the long run. Why not make the leap and
> >> show MS admins/developers how it should be done?
> >You really think they are all idiots?... Like, really?
> Sure, why not. MS admins/developers are all idiots who are apparently
> supposed to be taught by Cygwin developers who have been getting it
> wrong for many years until being correct by the OP.
> To the OP: If you want to start a dialog, do research and ask questions.
> Don't just assume that you understand everything and can provide insight
> that no one else has thought of.
I didn't say 'idiots', but I did LOL at Andrey's suggestion. Andrey, I'm beginning
to like you. By the way, your english really isn't that bad.
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
I searched the web extensively for an explanation on the newly imposed restriction.
I didn't find one yet. Only vague advice to not start services using the local
"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."
So I have to assume that it was to enhance Windows security. 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
Here's how they explain how to configure MS SQL Server (which uses impersonation),
but without explaining the underlying security model for services:
The only reference I can find about the service security model are the terms
"minimum rights" and "minimum privileges".
In Linux, the daemon security model is well-known and can be implemented by running
as an 'unprivileged user'. Sendmail uses this idea extensively.
Again, the only option I have at this moment is to run the Sendmail user (smmsp) as
an Administrator, so it can do impersonation. But this does *not* constitute
'minimum privileges', nor does this make the Sendmail user run as an 'unprivileged
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.
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
So, my original question was: can the Cygwin function 'getuid' be made to return '0'
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' if the program is running as the SYSTEM user or is
running with administrator rights?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple