This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Too Many Permissions Stripped In 1.7.35?


On Feb 28 17:04, random user wrote:
> Re the user SID != group SID, chmod -x case: Thanks, sorry to have
> wasted your time. It does seem the same on Linux, and chmod ug-x does
> appear to work correctly. My bad.
> 
> Re the user SID = group SID case:
> 
> I'm not offhand spotting how to use chmod to create the ACL your "They
> do:" example displays.

It hasn't been created with Cygwin.  I created it for the sake of
explaining how Cygwin evaluates an ACL to emulate POSIX permissions.

> With 1.7.35(0.286/5/3) 2015-02-27 17:16,
> Everyone permissions don't seem to leak into the group mode for the
> file owner user SID != group SID case. After a "chmod 607 x" where
> file owner user SID != group SID, I see in ls
>   -rw----rwx 1 XXX YYY 0 Feb 28 16:28 x

  $ chmod 607 xxx
  $ ls -l xxx
  -rw----rwx 1 corinna vinschen 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,X)
      VINSCHEN\corinna:(R,W,D,WDAC,WO)
      VINSCHEN\vinschen:(DENY)(W,RD,REA,X)
      VINSCHEN\vinschen:(Rc,S,RA)
      Everyone:(RX,W)

Does that explain it sufficently?

> For the user SID = group SID case, further testing seems to show that
> what gets presented now as the group mode is actually the bitand of
> the user and Everyone permissions. Is that correct?

No.  *At creation time of the ACL* the user bits are or'ed with
the group bits to constitute the user bits.  The *created* group bits
are 0:

  $ chmod 421 xxx
  $ ls -l xxx
  -rw------x 1 corinna corinna 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,X)
      VINSCHEN\corinna:(R,W,D,WDAC,WO)
      Everyone:(Rc,S,X,RA)

whereas in the user != group case:

  $ chmod 421 xxx
  $ ls -l xxx
  -r---w---x 1 corinna vinschen 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,WD,AD,WEA,X)
      VINSCHEN\vinschen:(DENY)(S,X)
      VINSCHEN\corinna:(R,D,WDAC,WO,WA)
      VINSCHEN\vinschen:(W,Rc,RA)
      Everyone:(Rc,S,X,RA)

> 
> (I had interpreted from the announcement email that group mode bits
> would show as = Everyone mode bits.)

I'm under the impression you're confusing things.  There are two
kinds of ACLs, the ones that have been created by Cygwin who's
trying to emulate POSIX permissions by creating the right kind
of deny and allow ACEs, and then there are ACLs of unknown source.
Even in case of the latter, Cygwin tries to translate them to POSIX
permission bits.  If you have a Windows ACL like this:

  user:      rw-
  group:     r--
  everyone:  --x

the resulting POSIX permissions are:

  user:      rwx
  group:     r-x
  other:     --x

Because Everyone is not the same as "other".  Permissions given to
everyone have to be mirrored into the permissions of user and group.

> >From an actual security point-of-view, seems either representation is
> reasonably accurate, as all the actual privileges granted are always
> shown in the user permission mode and there can't possibly be any
> "members of the group" other than the user for the group SID = user
> SID case. Is that thinking correct?

Yes.

> But the current approach seems to lead to inconsistencies at the
> appearance level. Everyone bits don't appear to fold into the group
> mode at all if user SID != group SID, as seen above.

Again, cygwin ACL != "some other" ACL.  The Cygwin ACL comes with
matching deny ACEs.

> There also seems an inconsistency introduced between the apparent
> group mode as it shows in ls and the group mask. Am I right in
> thinking that in Posix these are meant to be the same?
> 
> rm x
> umask 077
> touch x
> chgrp <same as user SID> x
> setfacl -m 'g:SYSTEM:r--' x
> ls -al x
> getfacl x
> chmod o+w x
> ls -al x
> getfacl x

Yes, there's an inconsistency and I'm not going to change it for now.

As I wrote in other mail, the code in question is split into two sets of
functions for historical reasons.  The stat/chmod/chown functionality is
one set, the acl(2) call is the other set.  I was trying to improve
acl(2) lately, but the underlying problem, two sets of functions with a
slightly different idea how things are suppsoed to be is getting in the
way.  That's why I'm going to rewrite this stuff later this year.


Corinna

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

Attachment: pgpw3bR8iag1o.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]