Re: symbolic link curiousity in 3.6.0

On 2025-04-10 15:47, Bruno Haible wrote: But what I could do is to change Gnulib's file-has-acl module so that if the environment variable CYGWINLY_PEDANTIC is set, Oh, let's not do that. We have too many environment variables already. Thanks for explaining.

Re: symbolic link curiousity in 3.6.0

Paul Eggert wrote: > On 4/9/25 04:09, Corinna Vinschen wrote: > > I would like to ask you to reconsider and to remove the > > Cygwin-special code and let Cygwin decide by itself, what a trivial vs. > > non-trivial ACL is by using the POSIXy functions Cygwin provides. > > Just use acl_extended_file(

Re: symbolic link curiousity in 3.6.0

On 4/9/25 04:09, Corinna Vinschen wrote: I would like to ask you to reconsider and to remove the Cygwin-special code and let Cygwin decide by itself, what a trivial vs. non-trivial ACL is by using the POSIXy functions Cygwin provides. Just use acl_extended_file(), please. Sorry, I've lost conte

Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15: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 u

Re: symbolic link curiousity in 3.6.0

On 2025-04-04 10:40, Pádraig Brady wrote: Is this patch is OK to be applied to gnulib, with the tweaks Corinna mentioned? Yes, I did that just now, and propagated it into coreutils.

Re: symbolic link curiousity in 3.6.0

On 2025-03-30 05:50, Corinna Vinschen wrote: The definition of O_PATH requires an additional #include Thanks, I added that and installed the patch into Gnulib. However, assuming not only Cygwin is affected, shouldn't the patch rather use O_PATH if it's available, O_RDONLY if not? I h

Re: symbolic link curiousity in 3.6.0

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

Re: symbolic link curiousity in 3.6.0

On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like a better approach. However, shouldn't it use O_PATH not O_RDONLY? We might lack read access. Does the attached Gnulib patch

Re: symbolic link curiousity in 3.6.0

Corinna Vinschen wrote: > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > one in test-file-has-acl.sh, and one (a problem of account handling in > Windows) in Cygwin's setfacl(1). Together with the above change to > acl_extended_file(), fixing the bug in setfacl(1) is suff

Re: symbolic link curiousity in 3.6.0

Hi Bruno, thanks for your quick reply! On Mar 28 15:30, Bruno Haible via Cygwin wrote: > [CCing bug-gnulib] > > Corinna Vinschen wrote in > : > > I found the problem, it's in a gnulib header. See below. > > ... > > Gnulib's acl-inte

Re: symbolic link curiousity in 3.6.0

Corinna Vinschen wrote: > Btw., there's still a small bug in test-file-has-acl.sh. It tries to > create an entry with gid 0: > > setfacl -m group:0:1 tmpfile0 > > But that's not possible, because there's no Windows group mapped to > uid or gid 0, unless you create your own /etc/passwd and /etc

Re: symbolic link curiousity in 3.6.0

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 t

Re: symbolic link curiousity in 3.6.0

On 29/03/2025 16:31, Paul Eggert wrote: On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like a better approach. However, shouldn't it use O_PATH not O_RDONLY? We might lack read a

Re: symbolic link curiousity in 3.6.0

On 3/31/25 12:26, Corinna Vinschen wrote: ls(1) always potentially shows a past state anyway. Sure, but traditionally (and I'm talking about 7th edition Unix) a single output line of 'ls' corresponded to a state obtained atomically from the file system. I realize we can't always do that nowad

Re: symbolic link curiousity in 3.6.0

On Mar 31 12:12, Paul Eggert via Cygwin wrote: > On 3/31/25 11:27, Pádraig Brady wrote: > > The file could be deleted at any time. > > We're just suppressing errors in the edge case it's deleted > > More generally, though, the file could be renamed and another put in its > place, which means that

Re: symbolic link curiousity in 3.6.0

On 3/31/25 11:27, Pádraig Brady wrote: The file could be deleted at any time. We're just suppressing errors in the edge case it's deleted More generally, though, the file could be renamed and another put in its place, which means that an attacker could cause 'ls' to generate a line that does

Re: symbolic link curiousity in 3.6.0

On 31/03/2025 17:32, Paul Eggert wrote: On 2025-03-30 07:26, Pádraig Brady wrote: On 30/03/2025 13:50, Corinna Vinschen wrote: In terms of coreutils, I think either ls(1) gobble_file() or file_has_aclinfo_cache() should still handle ENOENT from file_has_aclinfo() and not print any error message

Re: symbolic link curiousity in 3.6.0

On 2025-03-30 07:26, Pádraig Brady wrote: On 30/03/2025 13:50, Corinna Vinschen wrote: In terms of coreutils, I think either ls(1) gobble_file() or file_has_aclinfo_cache() should still handle ENOENT from file_has_aclinfo() and not print any error message.  After all, due to the preconditions fo

Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15: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 u

Re: symbolic link curiousity in 3.6.0

> > > 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

Re: symbolic link curiousity in 3.6.0

On 30/03/2025 13:50, Corinna Vinschen wrote: Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like

Re: symbolic link curiousity in 3.6.0

Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: > On 3/29/25 04:30, Corinna Vinschen wrote: > > What it should do if only the POSIX.1e draft 17 functions are available > > is something along these lines: > > Yes, that sounds like a better approach. However, shouldn'

Re: symbolic link curiousity in 3.6.0

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 G

Re: symbolic link curiousity in 3.6.0

On Mar 29 12:58, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > > one in test-file-has-acl.sh, and one (a problem of account handling in > > Windows) in Cygwin's setfacl(1). Together with the above change to > >

Re: symbolic link curiousity in 3.6.0

On Mar 29 13:12, Corinna Vinschen via Cygwin wrote: > On Mar 29 12:43, Bruno Haible via Cygwin wrote: > > 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 p

Re: symbolic link curiousity in 3.6.0

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 > >

Re: symbolic link curiousity in 3.6.0

Hi Pádraig, thanks for your reply! On Mar 28 20:30, Pádraig Brady via Cygwin wrote: > On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: > > [CCing bug-gnulib] > > > > Corinna Vinschen wrote in > > : > > Responding

Re: symbolic link curiousity in 3.6.0

On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: [CCing bug-gnulib] Corinna Vinschen wrote in : Responding to previous messages in the above thread, I think the triggering commit in coreutils 9.6 was: https://gi

Re: symbolic link curiousity in 3.6.0

On 2025-03-28 08:30, Bruno Haible via Cygwin wrote: [CCing bug-gnulib] Corinna Vinschen wrote in : I found the problem, it's in a gnulib header. See below. ... Gnulib's acl-internal.h contains this: /* Linux-specific */ /* C

Re: symbolic link curiousity in 3.6.0

[CCing bug-gnulib] Corinna Vinschen wrote in : > I found the problem, it's in a gnulib header. See below. > ... > Gnulib's acl-internal.h contains this: > > /* Linux-specific */ > /* Cygwin >= 2.5 implements this function, but it