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:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=Ud7xO+wl2axV2DxLJU0kqeVZeIEO4T7ccNph3Y422cYxRVY0yNcIS q5G6CE/WHjbXaV2/lWkeblaa2CMpk3H4MiJhRMKqZKBb6d7fYETC5QZO/Gz3652j /F4QvmJKinHk0qbRcicQ1SbcQZRgF/1vmYdOpjnaBfJJwcVCmuyD9E= 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:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=V89vo+yr8a+NbDuPsRbFL+3OJ3w=; b=Ge6kKQs3suqHCy/IrgrYK+SbVSyJ yvgR1on0ob2XaovLVYkXLM2Q+5zM2aWVgSWzxo1sKAI/nqSqBoiaooisAFugvQEl fW8bkg/Dy7324JaTzloRl3/2e/4kmipwmiVsvyx/1+rV3xMsZnJg0MNw3g4/tlAL 9Ln4Q6QY5uW9pVU= 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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Date: Wed, 1 Apr 2015 09:35:28 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: More about permissions Message-ID: <20150401073528.GA493@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <551B3EA8.4050607@cs.umass.edu> User-Agent: Mutt/1.5.23 (2014-03-12) --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mar 31 20:41, Eliot Moss wrote: > On 3/31/2015 4:55 PM, Andrey Repin wrote: >=20 > >> I am not sure this particular program (CrashPlan) works that way. > > > >That's not program property, but the user you run the program from. >=20 > Perhaps, but it runs as a background service. I never explicitly said wh= at > user it runs as, etc. >=20 > 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. >=20 > >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 shoul= d 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. >=20 > Yes, I get that. Hence my desire to grant SYSTEM:rwx on everything. >=20 > 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. Huh? ls -l (that is, stat(2)) shows the permissions in the same way as they are computed on a POSIX system. The mask value is just faked from the existing permsissions, but other than that, it does what POSIX 1003.1e requires. > 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 PO= SIX. I don't grok that. POSIX shows the permissions exactly as they are, with the group permissions being the primary group perms or the mask value if there is a mask. On Cygwin the mask is faked, but it shows the combined permissions of all non-primary users and groups, so it's a good fake. So in both cases the group permissions show you where's a security problem. Granting SYSTEM access to the kitchen sink is a Windows thingy, and a bad one as well. Rather than just asking the developers to enable the SE_BACKUP_NAME/SE_RESTORE_NAME rights when needed, they now add full access for SYSTEM and Administrators by default every time. That's a bad hack and totally unnecessary, too. But Cygwin adds SE_BACKUP_NAME/SE_RESTORE_NAME rights to the processes by default, so in theory you don't need full SYSTEM access inside your Cygwin tree. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVG5/AAAoJEPU2Bp2uRE+gNfsP/3jFCaYxkytFSnpIfTjQU3wU Nh7mwJ7UozHvZE7ZLu+iGn01nl9vBh+Tc+7RbABq4RDSePDP4hG/O7AYygGxWZqG qo78FIi3krefgNt2XhWtKlnDBwBKiCyeJq4QOd26vPwJsHvM1qKWbLGn1B65vpc7 BYZ7bH9PaxILOc5kyzydCgqxUDNmLxmOfzOIElBmUD6Z5h3LCvSy+l9ks2W/X/j2 8fmD3R90tfns+WxbehIKR65oekjDdQLBtg2OarLZQnBvs3HjOdQtDzj5J1fiVFUi r56kiqSd/asX0pVN9qB5IoF6QndOdGcYAURVzUvIXi683BnmwNbej0WlaWlE6A97 9oDUjNslfL5DUruoMlHaOarNhk2OZx1UFyq8ncxzDsolxkAjeS/lxbFOVO6Ol5m8 i3Oke2nIqDsqqDvqiXT+4BTcxxXn1FA49pR70AB6sUdVIFKSX9XyBt021N/a9J1U 6bQ93d7+jv291vSz3ZAA7w8EtEd4naGw1Yu5WmXA/SQvg/RYvTyKf0E7eOQkSAAT IaDALABs9CtZDsNzoTg8xfbrB0AhRSu11wTppAqjEWDp1hpm/gUaiiTY2rq6PQ5z qny/YcButh4d9tpSoN5otTsf6rxkxjimSF+y37JzwEot0m/pQ6u1iFqvg+eiUgr4 vo7810T6ZedFcq4enCzD =ewSe -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--