delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/03/31/06:15:57

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=kg9kIEFgKEW/dS1bC/PT5PGF/ftJ+ukvD0fMlz52kzbwFie9oMfEe
KLZ+b/IIF7rhAJCGwIzeFSvJBp7S4Zi7CHOXc28XYdYrXqAB5rD779XBBF++89Pj
AHlJRea8OcFa3Gey2rzaVLgkDppkgd/Aa89iny6iyBemm6+OnfMAdQ=
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=Ql+yTMuYp/Lsdj2zTVsjyETyboY=; b=BhZrruh2v9N5hgodZvye+9E2VnQm
EjXse9Dy/nmbQjbq92j9wRb/kk/p09A3PdzdDOjPXjvEAtJGgT9zgLKbevAPSL3n
4u8i4EyGDRxjIATsi4whwdVcMTy/hHPV9mfsJW9nOCa7QyfeZKgU38OHFvn/IHYS
GP0eAMKVib60JB8=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 31 Mar 2015 12:15:34 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: More about permissions
Message-ID: <20150331101534.GE32403@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>
MIME-Version: 1.0
In-Reply-To: <551A13D8.1030701@cs.umass.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

--+SfteS7bOf3dGlBC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mar 30 23:26, Eliot Moss wrote:
> Dear Cygwin community --
>=20
> Along with some others, I've been struggling a little to accommodate
> the changes to permissions handling that came lately.  I think I about
> have it figured out to work mostly Unix-like within my cygwin tree,
> but have one remaining thing I am wondering about, even though I have
> been through the ntsec document more than once.  (I think everyone
> will admit that this is complicated :-) ...)
>=20
> - I have created a new group, that I call Cygwin, to be the typical
>   group of cygwin-related files, so that I can control group permissions
>   appropriately. I am a member of that group.
>=20
> - I have found that if a directory is chmod to 2755 (2000 =3D=3D set gid)
>   and the directory's group is Cygwin, then cygwin-created files in
>   the directory get group Cygwin.  (This was not necessarily happening
>   before.)  To get this to happen, I had to list the sid of the Cygwin
>   group as my group in my line of the /etc/passwd file.  Otherwise the
>   group would be me, which does not seem to allow the same differentiation
>   of user versus group permissions.

The group s-bit is not yet taken into account.  If you have "Cygwin" as
your primary group in /etc/passwd or the account DB of choice (SAM/AD),
using 0755 as permissions should do the same thing.

Taking the group s-bit into account is part of my work-in-progress for
Cygwin 1.7.36.

> - I could not find an explanation of the 'mask' list by getfacl.  Near
>   as I can tell it is not really settable, although setfacl does not
>   complain, and it is the OR of the permissions of the various groups.

I explained that in the release annnouncement, I think.  The mask
value is required per POSIX, but it's faked on Cygwin yet, the reason
being that Windows doesn't know such a mask value.  I have an idea how
to make this work, but I need time for that.  The last two or three
weeks I had more than enough other stuff so I couldn't concentrate
on this, and it looks like this week is the same.

> Now, to what I would like to do.  Ideally I want SYSTEM to have rwx
> access to everything.  Seems a generally good idea on Windows, and at
> least r permission on files and rx on directories is needed for my
> backup program to access things.
>=20
> But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls
> always lists rwx for the group part of any such file, and chmod, if
> applied, affects SYSTEM's access bits.  What I'd like is for SYSTEM's
> role here to be hidden.  If there are any files where I want to restrict
> SYSTEM, I can use Windows tools or setfacl to manipulate them.
>=20
> Is this simply not possible with the new scheme?

No.  We discussed this at one point a few weeks ago, but it still seems
wrong to me to hide the permissions of any account.  Where does it end?
Is it only SYSTEM, or Administrators as well?  And then Domain Admins?
Backup Operators?  This contradicts the entire POSIX permission model.
I'm *very* reluctant to ignore accounts in permission handling.

Why does SYSTEM need full access to the files?  If it's a backup tool,
it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway.  Every tool with
Administrators in the token has the right to enable these access rights
anyway.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--+SfteS7bOf3dGlBC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVGnPGAAoJEPU2Bp2uRE+gF9EP/2ciNkKsfkiPE9VM7hh+K/K2
/VEL+y2LlhNeGBOpvCE+C0vQdQ3b6gBzdO6Cp6MY0BO1jp+uVIhyFzSMfuzFSUv7
4qsRYdreRtTqUaymvLEERiznGCy50IUeAD2Day0aA1bDksuoGDs4ADYN9b5is4zE
uM0lQbsuG7SbReIfbphLi87nPnyMohK89/Zf7oCEpMWXpoHpqIfAvVCC5sXx2j0M
9Npo3Fqby09SdS1L2ocF+yvhmCdYl8xjeoHMOwqxJguzAvgKzEFT47VekOJprWDp
P8aw+LXbZ0ty2Hw3tp97todrPDNcUatgOSrnBObSlBxd3zW5AnpH2O7KjEPS3y+P
x+FFdKKLXB+s4UKNW7OMXRp4F3x506Vx0MoJ9RzmPfiSMRiIuORCjUDJrqK9G2xS
JcTXwkJJyAC7/nXijIbmBNgq10wh698Jdxs8PRMSEm6aQ/LRh7R09dtgCy+JTDSX
v+9v4javMDNyXSDTen46Eg4Aa7BWABPiK/fhE8oZ5AWY0Cmkv/qoDOk4O7irQyFg
UZyv8BSsFl5SB4P02wCwTTaPmXR2Qwss2n5YBEJe1tFFUI9QKoMSbdbscJLfKSGj
a/sv45nMnjBQLUZS1wLXdGnFFd4lK7Rqs3FUlNjdO5wKztnBBxWhP5GkzgBPcOm/
lYjvH9wIKHz7EraVMGHl
=rqpx
-----END PGP SIGNATURE-----

--+SfteS7bOf3dGlBC--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019