DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TAGP4n754601 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52TAGP4n754601 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=cpZIOvtA X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D492D385AC24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1743243383; bh=OYMkTRqI+v44Uto9QfQVmwcZ1/teYU557rz/cGKY7EA=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=cpZIOvtAFx3aIrq/Fpgrfb9ka+9X45CIdP90ehXxb4lSm3VR1uklZBbnAKFK2Pe19 FMVlq3UpHmxntMEzDcuxzSaxLT9MguiiDSdwvddjpUzTZTBS/COsjPC10G4ih/nqDU u8oYpM6tmVhzvQ2SjRSZTAL2p/pgvsvRizoN6/G8= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FA993858C39 Date: Sat, 29 Mar 2025 11:15:16 +0100 To: Bruno Haible Cc: bug-gnulib AT gnu DOT org, cygwin AT cygwin DOT com Subject: Re: symbolic link curiousity in 3.6.0 Message-ID: Mail-Followup-To: Bruno Haible , bug-gnulib AT gnu DOT org, cygwin AT cygwin DOT com References:

<11037686 DOT 3WhfQktd6Z AT nimes> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <11037686.3WhfQktd6Z@nimes> X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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-internal.h contains this: > > > > /* Linux-specific */ > > /* Cygwin >= 2.5 implements this function, but it returns 1 for all > > directories, thus is unusable. */ > > # if !defined HAVE_ACL_EXTENDED_FILE || defined __CYGWIN__ > > # undef HAVE_ACL_EXTENDED_FILE > > # define HAVE_ACL_EXTENDED_FILE false > > # define acl_extended_file(name) (-1) > > # endif > > > > This is simply not true. Cygwin's acl_extended_file only returns > > 1 on dirs, if they actually contain more than the 3 default entries > > to emulate POSIX access. I just tried it and it works exactly > > as required. > > > > Can this be fixed, please? > > If I comment out that part: > /* || defined __CYGWIN__ */ > I get three test failures > > FAIL: test-file-has-acl.sh > ========================== > > file_has_acl("tmpdir0") returned yes, expected no > FAIL test-file-has-acl.sh (exit status: 1) > [...] > from a testdir created with > $ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure acl acl-permissions file-has-acl copy-file > > This is reproducible with both Cygwin 2.9 and 3.6.0. > > So, from my point of view, the situation is still the same as when > I introduced this workaround, in > https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00089.html > > Therefore, I see two possible ways forward: > a) The Cygwin function acl_extended_file gets modified so that it > is actually usable by Gnulib (i.e. does not cause test failures), > or > b) Investigate how to deal with the "Not supported" error in coreutils. > (Maybe silence and ignore this error?) Option b would be a change in coreutils, let's put that aside for now and stick to gnulib, becasue that decides over the actual library function used on Cygwin. In terms of gnulib, there's option a or an option c: c) The expectations of test-file-has-acl.sh are wrong. I only tested test-file-has-acl.sh so far, because it doesn't make sense to continue without clarifying the basics first. 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. - 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. - If you want acl_extended_file("a-dir") to return 0, run setfacl -bk a-dir So, how can we go forward here? - As far as I can see, acl_extended_file() is doing the right thing, so at first glance option c applies. - 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(). 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. That would be option a. I created a patch for Cygwin to behave as just outlined, and it makes test-file-has-acl.sh behave as desired, because acl_extended_file("a-dir") now returns 0 after mkdir. The ultimate question is, what is right or wrong? Cygwin can't change the way mkdir creates the default ACL without getting into trouble with non-Cygwin executables, so we either have to go with a) acl_extended_file() changing its behaviour to handle dirs created by mkdir as non-extended ACLs, or with c) Changing test-file-has-acl.sh to take the unique situation in Cygwin into account and acknowledge that Cygwin's acl_extended_file() returns a correct value. So, what is it, option a or c? ------------------------------------------------------------------ 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 sufficient to run test-file-has-acl.sh successfully. However: I ran the script with VERBOSE=1 and this is what is printed: [...] + chmod 600 tmpfile0 + acl_flavor=none + acl_flavor=linux [...] Oops, acl_flavor=linux? Turns out, the script checks the output for a --set-file option, which is supported by Cygwin's setfacl since commit ed4d919c24646 ("setfacl: Rename the option --file to --set-file, as on Linux"). Thanks, 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