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: Permissions change concern

On Apr 18 09:14, Eliot Moss wrote:
> On 4/18/2016 6:18 AM, Corinna Vinschen wrote:
> >On Apr 16 22:17, Eliot Moss wrote:
> >>The specific behavior I get is that chmod 644 on the file has no
> >>effect on the file's permissions - they stay at 774.
> >>
> >>So, has something in cygwin "broken", or is there some setting I
> >>should be doing a different way?
> >
> >It's broken.  I added a small code snippet in 2.5.0 which was supposed
> >to avoid writing a NULL SID ACE in case the POSIX permissions are simple
> >enough.  The condition under which to write the NULL SID ACE was...
> >uhm... not well thought through.
> >
> >I applied a fix and I built new developer snapshots available on
> >
> >
> >Please give'em a try.  Since I'm going on vacation end of this week,
> >I intend to provide a fixed 2.5.1 ASAP.
> Yes, that's better.  I still have two confusions, though:
> 1) If a directory says:
>   default:users::rwx
>   default:group::rwx
>   default:other:r-x
>   and my umask is 022
>   when I create a new file by "echo test >",'s
>   perms are 644, not the 755 I would expect.

Your example looks like 775.  But even then, the actual permissions
depend on the mode bits given to the open(2) call, which are usually 666
in this echo example.  The resulting perms should be 664.

Cygwin also takes the umask value into account if the newly created
ACL only contains default POSIX permissions.  That's not quite correct
in terms of POSIX 1003.1e draft 17, but in contrast to Linux, Windows
directory ACLs practically always have default ACEs, so we have to
compromise a bit, or umask just has no effect at all.  I fixed a 
problem with the permssion handling in case a mask value is present, but
that shouldn't matter in your case.

> 2) If the directory has g+s set (visible from -s- in the flags shown
>    by getfacl), the directory's group is Cygwin, and my primary group is moss,
>    then the file gets created with group moss, not group Cygwin (which is
>    what g+s is supposed to mean, right?)

There was still another bug in the same code snippet which disallowed to
set the special POSIX bits S_ISVTX/S_ISGID/S_ISUID under some
circumstances, but apart from that what you describe works for me if the
bit is set in the parent dir and the parent dir inherits entries.

But this only works if you create the file with a Cygwin executable and
the parent dir has inheritable ACEs.

I uploaded another snapshot to to make
sure the aforementioned bug can be tested as well.  Please check the
latest snapshot again.

However, if the s bit (aka S_ISGID) doesn't quite work as desired, I
have to defer any solution (if possible) until after my vaca.


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

Attachment: signature.asc
Description: PGP signature

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