On Mar 29 12:43, Bruno Haible via Cygwin wrote:
> Hi Corinna,
>
> > c) The expectations of test-file-has-acl.sh are wrong.
>
> The Cygwin-specific part of that unit test has minimal expectations:
>
> # Set an ACL for a group.
> if setfacl -m group:0:1 tmpfile0; then
>
> func_test_has_acl tmpfile0 yes
>
> # Remove the ACL for the group.
> setfacl -d group:0 tmpfile0
>
> func_test_has_acl tmpfile0 no
>
> fi
>
> Namely:
> - After we set an ACL for a group, there is an ACL.
> - After we remove this ACL, there is no ACL any more.
That is affected by the setfacl problem I mentioned in my previous mail.
I don't know if it's worth discussing. If you think so, I'm happy to
oblige.
> > Here's what happens:
> >
> > - When you create a dir in Cygwin, the dir will get a Windows ACL
> > which is equivalent to a POSIX ACL with 6 entries:
> >
> > $ mkdir /tmp/glo1FkFx/tmpdir0
> > $ getfacl /tmp/glo1FkFx/tmpdir0
> > # file: /tmp/glo1FkFx/tmpdir0/
> > # owner: corinna
> > # group: vinschen
> > user::rwx
> > group::r-x
> > other::r-x
> > default:user::rwx
> > default:group::r-x
> > default:other::r-x
> >
> > We have to do this to make sure that native (i. e. non-Cygwin)
> > processes creating files inside of the new dir will by default create
> > ACLs which conform to the POSIX rules. Note that Cygwin processes
> > don't need the default ACL entries, but, alas, we're not alone in the
> > world.
>
> OK, and what does this mean for the *files* created in such a directory?
Just for clarity, permissions in Windows are *always* defined by an ACL.
There's no such thing as default POSIX perms. Don't try to look at
non-Cygwin-created files from a POSIX permission POV, it's a lost cause.
But your question was specificially about files created in the above
dir:
- Files created by a Cygwin process inside that dir will have only the
usual three ACL entries constituting standard POSIX permission bits,
combined with their umask, i.e.:
$ cd /tmp/glo1FkFx/tmpdir0
$ umask
22
$ touch foo
$ getfacl foo
# file: foo
# owner: corinna
# group: vinschen
user::rw-
group::r--
other::r--
- Files created by non-Cygwin processes inside that dir will have by
default(*) only the usual three ACL entries constituting standard
POSIX permission bits, but there's no umask handling in the non-Cygwin
process, i.e.
$ cd /tmp/glo1FkFx/tmpdir0
$ cmd
C:\cygwin64\tmp\glQatIoG\tmpdir0>echo foo > bar
C:\cygwin64\tmp\glQatIoG\tmpdir0>exit
$ getfacl bar
# file: bar
# owner: corinna
# group: vinschen
user::rwx
group::r-x
other::r-x
(*) Most Windows processes rely entirely on the permissions in
the ACLs and the Windows ACL inheritance rules.
Does that answer your question?
> > - However, being the POSIX-conformant citizen we try to be, Cygwin's
> > acl_extended_file() *only* returns 0 if the ACL contains three
> > entries. Any ACL of three entries consists of the default POSIX
> > permissions for user/group/other only.
> >
> > - Therefore, a Cygwin-generated dir with default permissions is always
> > an extended ACL by default.
> >
> > - Outside of a Cygwin-generated directory tree, plain Windows rules
> > apply, and Windows ACLs generated under Windows rules are always
> > extended ACLs (with a 99.9% probability) from a POSIX POV.
> >
> > - Therefore, 99.9% of the time, acl_extended_file("a-dir") returns 1,
> > and *correctly* so from the POSIX POV.
>
> This sounds all reasonable from the points of view of
> - Windows interoperability,
> - compliance with the never-standardized POSIX ACL specification
> (see <https://en.wikipedia.org/wiki/Access-control_list#POSIX_ACL>).
>
> The point of view that I'm using in Gnulib is that it must make sense
> for the end user, that is, for the user who creates files and shares
> files with other users on the same machine. For such a user
> - the absence of an ACL means "the usual chmod based permissions matter",
> - the presence of an ACL means "attention! special rules! run getfacl
> to make sure you understand what you are doing".
> The GNU coreutils 'ls' program helps the user making this distinction,
> by displaying a '+' sign after the permissions field.
>
> An ACL implementation that shows a '+' sign on 99.9% of the files is
> not useful. A user can't practically run 'getfacl' on all files and
> understand the result. In other words, ACLs need to be the special case,
> not the common case.
Yeah, that's a good point. If the user is beaten with a stick with
a '+' sign written on it, it's basically no help.
> > - But I can also see the point that a directory created with mkdir
> > should start out with a standard POSIX ACL.
> >
> > We can't do that literally for the reason cited above, but we *could*
> > change acl_extended_file().
>
> Yes, if you change Cygwin's acl_extended_file(), Gnulib might be able
> to use this function.
Ok.
> > It could check a directory ACL, if it
> > only consists of 3 or 6 ACL entries, and if it consists of 6 entries,
> > the entries 4 to 6 *must* be the default entries for user/group/other.
>
> I'm not so bothered with directories (because directory ACLs are one level
> of complexity above the file ACLs, and Gnulib never got to the point of
> having a reasonable cross-platform behaviour of directory ACLs), rather
> with files. What is the change to acl_extended_file() on files that you
> are considering?
None. For files created in a Cygwin directory tree, everything is
working as desired with acl_extended_file() just checking for the three
standard ACL entries constituting the POSIX permission bits
(owner/group/other).
For non-Cygwin-generated files, there's no such thing as a standard ACL,
and the Cygwin user, looking from the POSIX perspective when using it,
should see the '+'-sign to notice this file has no POSIX permissions.
> > The ultimate question is, what is right or wrong?
>
> Regarding what Gnulib does, I explained above.
>
> Regarding what acl_extended_file() does, there is the man page by
> Andreas Grünbacher:
> https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html
> Gnulib is not the only user of acl_extended_file(); therefore I would
> suggest that Cygwin should follow that man page — regardless of Gnulib.
It already does! The acl_extended_file() change for directories we just
talked about will actually be a deviation from Andreas' man page.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
