This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The eternal uid issue

Hi Christopher,

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.
> cgf

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
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."

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
!= 0). 

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]