Issue with cygdrive mount, native symlinks, and noacl option

Issue with cygdrive mount, native symlinks, and noacl option

[Christopher Layne]

I noticed recently while attempting to rsync directories from one drive to another that I was getting the familiar "NULL SID", "incorrectly ordered", etc. type ownership issues on the destination even though I use noacl for cygdrive mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence why I use "noacl" for cygdrive). I was able to track down the issue to a specific combination of things that creates the problem:

1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s /cygdrive/<x> /<x>.
2. All symlinks are actually native reparse points as a I run with CYGWIN=winsymlinks:nativestrict by default.

Example:

clayne@sv590:/ $ ls -lad /[a-z]
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s

3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ /s/some-dir/

The issue here is that it appears mount related options such as noacl are evaluated differently when native symlinks are used. If I change the destination to instead be "/cygdrive/s/dest/dir" then noacl works appropriately. On top of all this, if I instead create the /s symlink as a "cygwin" style symlink via CYGWIN=winsymlinks things also work correctly - that is, the noacl option is used. What I would intuitively expect, atleast within the context of acl vs noacl, is for the symlinks to be resolved first and then mount options specific to the target resolved based off what the symlink actually points to. In the native/nativestrict case, it appears to be doing this in reverse and inheriting /'s standard default acl option rather than /cygdrive's noacl option.

Footnotes on workarounds:

* I know how to workaround using the root-level symlinks in the first place by just mounting cygdrive to /, but I'd have to update various scripts which already use /cygdrive and I like having the "windows drives" self-contained under /cygdrive (even though I frequently use the / level symlinks as shorthand).
* I also know how to avoid the issue entirely by using /cygdrive/<x> for the destination but the underlying issue still seems like a bug or an oversight to me, particularly given that nativestrict behaves differently when it comes to evaluating mount options.
* Another workaround would be to use non-nativestrict symlinks but I want to preserve interoperability with native windows applications outside of cygwin and I've learned over the years to just avoid anything that isn't nativestrict.

Here's a repro case:

clayne@sv590:~ $ uname -a
CYGWIN_NT-10.0-19045 sv590 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin

clayne@sv590:~ $ cat /tmp/link_test 
#!/bin/bash

set -e
set -o pipefail

rm -rf /cygdrive/{f,s}/link_test
mkdir -p /cygdrive/{f,s}/link_test
echo foo > /cygdrive/f/link_test/test

for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict; do
       	export CYGWIN="$i"
       	link="s_${i//:/_}"
       	ln -sfT /cygdrive/s /$link
       	rsync -aSH /f/link_test/ "/$link/link_test/$link"/
       	ls -la /$link/link_test/$link/test || true
       	getfacl /$link/link_test/$link/test || true
done

clayne@sv590:~ $ bash -x /tmp/link_test 
+ set -e
+ set -o pipefail
+ rm -rf /cygdrive/f/link_test /cygdrive/s/link_test
+ mkdir -p /cygdrive/f/link_test /cygdrive/s/link_test
+ echo foo
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks
+ CYGWIN=winsymlinks
+ link=s_winsymlinks
+ ln -sfT /cygdrive/s /s_winsymlinks
+ rsync -aSH /f/link_test/ /s_winsymlinks/link_test/s_winsymlinks/
+ ls -la /s_winsymlinks/link_test/s_winsymlinks/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 /s_winsymlinks/link_test/s_winsymlinks/test
+ getfacl /s_winsymlinks/link_test/s_winsymlinks/test
getfacl: /s_winsymlinks/link_test/s_winsymlinks/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:lnk
+ CYGWIN=winsymlinks:lnk
+ link=s_winsymlinks_lnk
+ ln -sfT /cygdrive/s /s_winsymlinks_lnk
+ rsync -aSH /f/link_test/ /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/
+ ls -la /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
+ getfacl /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
getfacl: /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:sys
+ CYGWIN=winsymlinks:sys
+ link=s_winsymlinks_sys
+ ln -sfT /cygdrive/s /s_winsymlinks_sys
+ rsync -aSH /f/link_test/ /s_winsymlinks_sys/link_test/s_winsymlinks_sys/
+ ls -la /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
+ getfacl /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
getfacl: /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:nativestrict
+ CYGWIN=winsymlinks:nativestrict
+ link=s_winsymlinks_nativestrict
+ ln -sfT /cygdrive/s /s_winsymlinks_nativestrict
+ rsync -aSH /f/link_test/ /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/
+ ls -la /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
-rwxrwx---+ 1 clayne None 4 Apr 24 13:38 /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
+ getfacl /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
# file: /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
# owner: clayne
# group: None
user::rwx
group::r-x
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask::rwx
other::---

I obviously can't include explorer screencaps, but suffice to say, "winsymlinks:nativestrict" is the only one that ends up with NULL SID, incorrect order, etc issues on the synced files.

-cl

Re: Issue with cygdrive mount, native symlinks, and noacl option

[Andrey Repin]

Greetings, Christopher Layne!

> I noticed recently while attempting to rsync directories from one drive to
> another that I was getting the familiar "NULL SID", "incorrectly ordered",
> etc. type ownership issues on the destination even though I use noacl for
> cygdrive mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence
> why I use "noacl" for cygdrive). I was able to track down the issue to a
> specific combination of things that creates the problem:

> 1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s /cygdrive/<x> /<x>.

Just make cygdrive prefix / in this case.
Portable apps should use /proc/cygdrive/ regardless.

> 2. All symlinks are actually native reparse points as a I run with
> CYGWIN=winsymlinks:nativestrict by default.

> Example:

> clayne@sv590:/ $ ls -lad /[a-z]
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s

What is the actual symlink target? (not what is reported by Cygwin)

> 3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ /s/some-dir/

> The issue here is that it appears mount related options such as noacl are
> evaluated differently when native symlinks are used. If I change the
> destination to instead be "/cygdrive/s/dest/dir" then noacl works
> appropriately. On top of all this, if I instead create the /s symlink as a
> "cygwin" style symlink via CYGWIN=winsymlinks things also work correctly -
> that is, the noacl option is used. What I would intuitively expect, atleast
> within the context of acl vs noacl, is for the symlinks to be resolved first
> and then mount options specific to the target resolved based off what the
> symlink actually points to. In the native/nativestrict case, it appears to
> be doing this in reverse and inheriting /'s standard default acl option
> rather than /cygdrive's noacl option.

> Footnotes on workarounds:

> * I know how to workaround using the root-level symlinks in the first place
> by just mounting cygdrive to /, but I'd have to update various scripts which
> already use /cygdrive and I like having the "windows drives" self-contained
> under /cygdrive (even though I frequently use the / level symlinks as shorthand).

See the note above about portable apps.

> * I also know how to avoid the issue entirely by using /cygdrive/<x> for
> the destination but the underlying issue still seems like a bug or an
> oversight to me, particularly given that nativestrict behaves differently
> when it comes to evaluating mount options.

See...

> * Another workaround would be to use non-nativestrict symlinks but I want
> to preserve interoperability with native windows applications outside of
> cygwin and I've learned over the years to just avoid anything that isn't
> nativestrict.

I'm with you here.


-- 
With best regards,
Andrey Repin
Friday, April 26, 2024 10:20:43

Sorry for my terrible english...