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: 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=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 Reply-To: cygwin AT cygwin DOT com Message-ID: <23917301.20140724171122@yandex.ru> To: "D. Boland" , 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 Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit 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...