On 2025-03-29 12:14, Brian Inglis via Cygwin wrote:
On 2025-03-29 08:02, Bruno Haible via Cygwin wrote:
Corinna Vinschen wrote:
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.
OK, then Cygwin's acl_extended_file should not change.
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.
Glad to have an agreement here. Then, gnulib won't change: it will not
use Cygwin's acl_extended_file() function and instead use the function
acl_access_nontrivial(), defined in Gnulib.
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?
Thanks for explaining. This matches my earlier experiments on Cygwin;
see these comments in the acl_access_nontrivial function:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl-
internal.c;h=6c50feacbb811da92da9a68d544132d87ad8dbf3;hb=HEAD#l80
So, in summary, I too see the action item (regarding the behaviour
of 'ls' on symlinks) more on the coreutils side.
Please reiterate what you see needing to be patched in coreutils 9.6 - just your
patch 0001-file-has-acl-port-symlink-code-to-Cygwin.patch or something else?
Dogfooding coreutils 9.6 since release - now also under Cygwin 3.6 - permissions
on build symlinks:
$ uname -srvmo
CYGWIN_NT-10.0-19045 3.6.0-1.x86_64 2025-03-18 17:01 UTC x86_64 Cygwin
$ ls --version
ls (GNU coreutils) 9.6
Packaged by Cygwin (9.6-1)
Copyright (C) 2025 Free Software Foundation, Inc.
...
Sorry - will make more sense with symlink entry:
$ ls -l coreutils-9.6-1.x86_64/build/GNUmakefile | cyg-sanitize-output.sed
lrwxrwxrwx 1 $USER None 71 Feb 10 14:45
coreutils-9.6-1.x86_64/build/GNUmakefile ->
/usr/src/coreutils/coreutils-9.6-1.x86_64/src/coreutils-9.6/GNUmakefile
[and if I cc Bruno and bug-gnulib]
$ lsp coreutils-9.6-1.x86_64/build/GNUmakefile # ls, getfacl, icacls
-rw-r--r-- 1 $USER None 4589 Jan 17 07:46 .../build/GNUmakefile
# file: coreutils-9.6-1.x86_64/build/GNUmakefile
# owner: $USER
# group: None
user::rw-
group::r--
other::r--
.../src/coreutils-9.6/GNUmakefile $HOSTNAME/$USER:(R,W,D,WDAC,WO)
$HOSTNAME/None:(R)
Everyone:(R)
Successfully processed 1 files; Failed processing 0 files
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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
