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:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=HFiZXnQrDkw1pBEqv+0oz2xfqf2eCElRGOCzIJDfhRe/S1AVd9wh5 +6ZKzh/NzhI1a8U1j5qiPJmW9+dWBV4GxGnTyYwwtaCj1RsLe05wlFiFOkZ8Quh4 8BQkclIx5kYx4pfusX+NTK8mXnOsvBh9k/YYzpkONtOyy4TyJanDl0= 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:to:from:subject:date:message-id:references :mime-version:content-type:content-transfer-encoding; s=default; bh=wfAVNz9JUR1rmmrdtJNrfKHu4nk=; b=VV762Wcqko+tIKSCjZmBscFmjGjY xZyn5EdIG6ek/BC4sAJvdM6MVWyDYib/SSt6Fa/iGJA8/x2NnYXzAUOwsKSx1Le1 zLQRGKDLmhYp3FCo1nJCHiSX53hmfys0NUdC6zDD3hSy83UWDrd8h6WM8PXChzbu Kbr8CqjqMSpr8LE= 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=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: plane.gmane.org To: cygwin AT cygwin DOT com From: "D. Boland" Subject: Re: The eternal uid issue Date: Thu, 24 Jul 2014 11:34:14 +0200 Lines: 84 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 system’s 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