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 for SYSTEM. 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 systems computer account, accessing Configuration Manager 2007 files and data through those other systems." -- source: http://technet.microsoft.com/en-us/library/bb680595.aspx 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 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". 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 user'. 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? Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
