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=nlqlJjyWWp5Qh2KpBXxXMrmmYTlgSYwu0IxltOX8xzKEAWDSGUWur
	NaaZ0EyuHJK8FW6gavnZDU9gSlN5nSz/+CDpqFCSMg2AnpFNXhHyIRheMj/qTExT
	MOMpFnEvJz6LVZBIuv9EZP5TFbGmO1rLk15W6pALR72pkE21oZaNeg=
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=YR78EbWjJ9rWX0eghu4khy8lRoo=; b=gcPP6lA5b5xD3BlJOdJ4ocdWDmXD
	CIshDZzH5K4utxaWHMNGmhhRmcqs9gsw09wtITkmSJ5uE5IpP+6RUFQBZSq6wIny
	LHGb8Pv7z1sauhYPGmJ8JV3mh3ygVZqr0T/RNN7yXoBlp3fFrUb4SWSFOvLlJ4Iq
	rI/wOiPeqY0masw=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=-0.9 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" <daniel AT boland DOT nl>
Subject:	Re: The eternal uid issue
Date:	Wed, 23 Jul 2014 13:35:43 +0200
Lines:	47
Message-ID:	<53CF9E0F.F596FC60@boland.nl>
References:	<53CF6CEC DOT 6D68E485 AT boland DOT nl> <20140723091409 DOT GH27005 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
X-IsSubscribed:	yes

Hi Corinna,

Corinna Vinschen wrote:
> 
> > Isn't it about time to make this our First Directive also?
> 
> Not in relation to the uid.  In contrast to Linux we don't have the one
> single root user.  We have potentially endless numbers of them, and one
> of them, not necessarily SYSTEM, is used to run the service.  Keep in
> mind that there may also be company policy in place which disallows
> installing services under specific accounts unless absolutely necessary.
> 
> Therefore, while we mostly strive to make Cygwin accommodate user
> space, we're not able to do it related to the root uid.
> 

Thanks for your lengthly and detailed answer. I appreciate that. But don't you think
upstream maintainers will raise at least one eyebrow if we propose code that makes
any user who starts the program the root/admin user?
You suggest only those who are in the admin group. But that will soon be any service
that starts up.

It actually is my solution to running Sendmail: create the Sendmail user, called
'smmsp' and make it an Administrator, so it can impersonate users on my system.
But I don't like my solution, because this would mean I have to create an admin-user
for any Linux service that I install. So now my Cygwin setup would be crowded with
highly
privileged daemons, listening, waiting to get hacked.

The more elegant solution would be to create only one secondary privileged user,
let's call it 'root' ;-). Now Sendmail can start as root, switch to the totally
*unprivileged* 'smmsp' user and receive mail.
Of course the real bonus is that these unprivileged users wouldn't need passwords,
since they are impersonated, not logged on. These would consequently be
*super-secure* users, because it is impossible to login with an empty password.

Why is this related to the uid issue? I already tested the second solution. I found
out that if I assign my 'root' user the '0' id in /etc/passwd, it actually works. I
was delighted, because I could roll-back all these weird changes I put in the
Sendmail/procmail/mail.local source to fix the getuid != 0 problem.

If we go with this MS-imposed idea of "putting services in admin-context", 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?

Sincerely,
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

- Raw text -