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]


Hi Cygwin friends and users,

I released a new Cygwin TEST version 2.5.0-0.2.

This new test release introduces a change which also affects users in
terms of the POSIX file permission handling.  One of them is a bugfix:

- Under some circumstances you could observe a spurious entry for
  the owning group with no permissions at all, e.g.:

    $ getfacl foo
    # owner: hein
    # group: bloed
    group:bloed:---     <--- spurious, this should be gone now

- Usually POSIX.1e requires that chmod does not change the group
  permissions but the MASK permissions if additional user and group
  entries are present.  This may result in a confusing behaviour:

    $ getfacl -c foo

  So the primary group only has read perms.  Now let's see what happens
  when calling `chmod g+w':

    $ ls -l foo
    -rwxr--r--+  [...] foo
    $ chmod g+w foo
    $ ls -l foo
    -rwxrw-r--+  [...] foo

  Looks good so far, but...

    $ getfacl -c foo
    group::r--        <-- Still only read perms, no write perms
    mask::rw-         <-- Only the mask has changed
  So chmod g+w does NOT result in the primary group getting write
  permissions if it doesn't already have them.  This is one of the
  more puzzling aspects of POSIX.1e.

  The chmod change in 2.5.0 now handles default Windows ACL with entries
  only for the owner, the group, other, SYSTEM and the Administrators
  group as if it's a standard POSIX ACL.  That is, chmod will not only
  influence the POSIX MASK entry, but also the owning group entry.  The
  result should be more along the lines of Windows user expectations
  when calling chmod.  Note that this is restricted to *only* the ACLs
  described above.  Any other group present in the ACL will switch
  chmod back to the POSIX.1e behaviour.

Other than that, this release still introduces a major change addressing
developers only.

tl;dr: Cygwin 2.5.0 switches Cygwin from the Solaris ACL API to the
       POSIX.1e ACL API.

Since the year 2000, Cygwin supports a POSIXoid ACL emulation.  This
emulation is based on the Solaris API, which is only marginally
comparable to the POSIX ACL API defined in the withdrawn draft

At about the same time SGI started to implement POSIX.1e which
eventually became libacl in 2001.  Libacl is the POSIX ACL
implementation used on Linux.

With Cygwin 2.4.0, Cygwin introduced a major revamp of the POSIX ACL
emulation.  This new emulation is complete in the sense that the ACL
handling covers all of POSIX.1e quirks.  This in turn allows to use
the POSIX.1e API.

The Solaris API is the base implementation and stays available.  The
POSIX.1e API is implemented in terms of the Solaris types and mainly
a slim layer on top of the Solaris API.

Changes for developers:

- The full set of POSIX.1e functions is now available.

- Most of the libacl extensions are available as well.  The only
  exceptions right now are the two functions perm_copy_file and
  perm_copy_fd.  These can be added later.  Somebody just has to do it :)

- The <sys/acl.h> header now *only* exposes the POSIX.1e API.

- To get access to the Solaris API, you will have to include
  <cygwin/acl.h> now.

- There's a new header <acl/libacl.h> which exposes the libacl extension

Please give this new POSIX.1e ACL implementation a test.  If you have
a project or maintain a package utilizing ACLs, please make sure that
your project picks up the new POSIX.1e API and that it works as desired.

Have fun,


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

Problem reports:
Unsubscribe info:

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