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: Issues with ACL settings after updating to the latest cygwin.dll

On Feb  9 20:53, xnor wrote:
> >Not sure what Transmission is, but files downloaded with POSIX
> >tools are usually not executable.  For instance, download Cygwin's
> >setup-x86.exe with wget.  Then try to execute it.  It won't since
> >the permissions are set according to your umask and without execute
> >permissions, e.g., 0644.  This is normal.
> The behavior has changed with the ACL change in Cygwin and I would not
> consider that "normal". The warning from Windows is not normal.

Which warning do you mean here?

> I realize that the previous implementation was already problematic and
> messed with permissions but I did not notice it since it never denied
> executing executables.

No, but either way, the created ACL is not necessarily what Microsoft
describes as "canonical".  POSIX permissions just don't map well with
canonical-only ACLs.

The problem right now is that I can't reproduce what you encounter.
That's why I'm asking for the details in terms of the ACL, that is,
output from icacls and getfacl to compare the output and ideally
being able to reproduce and, even more ideal, fix it.

Come on, be fair.  The new ACL handling started out early 2015, got a
break when I realized that it doesn't work as is, and then got a new
test phase starting back in September.  Except for minor bugs it seemed
to work rather well.  Nobody reported this effect in all the 4 months of
test period.  You don't actually think I wouldn't have fixed it prior
to the release if I had known about it, do you?

> >The permissions must *not* be reordered.  If Cygwin creates permissions
> >incorrectly it's one thing, but the order to emulate POSIX permissions
> >is non-canonical.  Reordering them will break them.
> >
> >Please provide the exact output from icacls.
> They *have* to be reordered to be modifiable in Windows/Explorer. In other
> words, if I want to change permission the new ACL behavior ensures that it
> breaks the Cygwin permissions?

They are not supposed to be modifiable in Explorer.  If you want to
change permissions on a Cygwin ACL, use chmod or setfacl.

> Here is the output from icacls /saveacl for some file:
> D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)

Doh, I'm sorry, but I can't read this format very well.  Can you please
again send the standard icacls output as well as the output from getfacl
of the parent dir and the created file?  I'd like to have this problem
fixed, but I need your help.  As I said, it works fine for me and without
being able to reproduce I'm somewhat at a loss.

> Here is what's "normal" for Windows if I create a file under a new folder on
> C: in Explorer:

If you don't want POSIX perms, but standard Windows perms, use the "noacl"
mount option.  See

> Here is what I would expect:
> MyUser is in the group Administrators. Given the inherited permissions above
> a Windows-created file should be shown as "-rwxrwxr--+ MyUser
> Administrators"?

Sorry, can't do that, *unless* you make "Administrators" the primary
group in your user token(*).  Even though your account is *member* of
the Administrators group, the group is *never* your primary group per
Windows.  All local accounts, independently of their group memberships,
have the group "None" as their primary group.  That's how Windows works,
and that hasn't changed since at least NT4.

Unless, of course, if you use a so-called "Windows account", one of
those accounts which you login with using your email address (was that
introduced with Windows 8?  I'm not sure).  In that case, the primary
group in your user token is set to your user account itself.  So your
primary group SID is your own user SID.  Duh!


(*) There *is* a way to do that, but only inside Cygwin, see

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]