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=nbctfuf0QSB1AE8H
	5c/L3+qjXZZdc/a4BbxW3zgXSU2uuV5AmCHhyHMHk9NJzuY7i7E1/2yuUp5ehd1j
	6UUn59GGKNLxyJVEKvHK1a86fvc53n18dOWsyhI8kgjjiobu5VzsPu17xDhF7Ywu
	tY6zeI473DDOCdRvCaXTasw5iZo=
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=ItMePGlUQLXb4LVJNZtfoE
	Luing=; b=gU6l3z3XjqyOig9pP0r/hNZKGNlOmPDoemkIr3OlJDqU8QUx+OyZSl
	6NAFy8kv6YLH0wAqDl+JcVE3YYFpy8Z+oK8CGKWlvdtQSdAsmFSGea40rM+k+oTK
	T2HbAVTFs/K3JkrL8GOB/tJ2gUnOnbOUsyESOs28o0+sBfTIaOmrM=
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.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,KAM_THEBAT,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO: smtp.ht-systems.ru
Date: Wed, 1 Apr 2015 03:52:40 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <392349513.20150401035240@yandex.ru>
To: Eliot Moss <moss AT cs DOT umass DOT edu>, cygwin AT cygwin DOT com
Subject: Re: More about permissions
In-Reply-To: <551B3EA8.4050607@cs.umass.edu>
References: <551A13D8 DOT 1030701 AT cs DOT umass DOT edu> <20150331101534 DOT GE32403 AT calimero DOT vinschen DOT de>     <551A9149 DOT 4020408 AT cs DOT umass DOT edu> <1837571490 DOT 20150331235503 AT yandex DOT ru>  <551B3EA8 DOT 4050607 AT cs DOT umass DOT edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Greetings, Eliot Moss!

 >>> I am not sure this particular program (CrashPlan) works that way.
>>
>> That's not program property, but the user you run the program from.

> Perhaps, but it runs as a background service.  I never explicitly said what
> user it runs as, etc.

> Looking in Services, I see is logs on as "Local System account".  Using
> Process Explorer, it appears to run without SEBackup/Restore privileges.
> Since the program has to request them itself as it runs, I don't see any
> good way to fix this.

Well, then, as Corinna said, the task isn't up to the job, if it doesn't
enable necessary privileges.
Either way, this is an offtopic.

>> I think i've explained it earlir, but here's it again:
>> In POSIX model, root have implicit permissions.
>> In Windows model, there NO implicit permissions at all. Everything should be
>> explicitly assigned. I.e. SeBackupRestore privilege.
>> If you deny SYSTEM access to a file, OS will not be able to do anything about
>> it. Been there, blocked changes to cmd.exe when I was experimenting with 4NT.
>> (And cmd.exe was in fact renamed 4nt.exe.) None of the Windows autotools were
>> able to get around it.

> Yes, I get that.  Hence my desire to grant SYSTEM:rwx on everything.

That's one way to solve your issue, but not a correct way.

> What we seem to have ended up with here, though, is that the
> root privileges are explicit and are exposed in the ordinary permissions visible
> with, say, ls -l.  This is not natural from a POSIX point of view (I claim);
> otherwise, we'd more or less show access of rwxrwxrwx on everything in POSIX.

> Now where this really makes a difference is when I am transferring files between my Windows
> system and other systems that are Unix-based, using git, rsync, and such tools.
> Either I remove SYSTEM access or the permissions get messed up.

That's one of the reasons why I think SYSTEM account privileges needs to be
hidden from POSIX access mask. It needs to be shown in getfacl to reduce
confusion, though, but otherwise there's no case, where hiding it could cause
any more harm, than showing it.

>>> Maybe what I am looking for is something like this:
>>
>>> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>>>     purposes, perhaps controlled by a list in a file read when cygwin starts up.

>> The list would be very short. "NT AUTHORITY\SYSTEM".

> Ok -- I would be happy with that, rather than having g+rwx happening to every
> file because I am granting SYSTEM access.

> Do you begin to see the bind I feel myself in?

Do tell me? I'm perpetually caught in it.


-- 
With best regards,
Andrey Repin
Wednesday, April 1, 2015 03:47:24

Sorry for my terrible english...


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