rrsync: support fd pins in user namespaces

[steadytao]

Fixes #1044

Summary

• allow the exact /proc/self component of a recognised rrsync fd pin when procfs reports its owner as the overflow UID inside a user namespace
• retain the normal symlink-owner and confinement checks for every other component and for the resolved fd target
• add a regression test that enters an unprivileged user namespace and exercises a confined /proc/self/fd/N log path

[tridge]

@samueloph please test

[samueloph]

@tridge @steadytao I confirm this solves the problem on Debian

[seks99x]

@steadytao Great job on this fix! I did notice one small edge case during testing, if we change the test to use /dev/fd/ instead of /proc/self/fd/, the test still fails. It looks like /dev/fd/ will require some extra handling or allowlisting alongside /proc/self/fd/

----- new log follows
confined log path through an fd pin was rejected (rc=0, stderr='rsync: [client] failed to open log-file /dev/fd/3/rsync.log: Too many levels of symbolic links (40)')
user-namespace regression test failed (rc=1)
----- new log ends
FAIL    fd_test
------------------------------------------------------------
----- overall results:
      0 passed
      1 failed
------------------------------------------------------------
overall result is 1

[steadytao]

Thanks... /dev/fd reaches a different kernel magic-link path. I would keep this change limited to the user-namespace /proc/self ownership exception rather than broaden the confined path traversal here.

[steadytao]

Just realised that #1054 would probably cover it anyways

[steadytao]

Yes it would, should be good to merge this.

[seks99x]

Actually I don't think this is covered in #1054 because I didn't modify any permission changes but we could fix that on the same PR if you would like.

[steadytao]

Ah, yeah, I just assumed from 1053's scope. Nonetheless, I don't fully see why we need to broaden the confinement exception to /dev/fd/N seeing as those pins are never generated?

[seks99x]

Im not with broadening as what you saying. The issue is Bash process substitution uses /dev/fd. If the same case happened using Bash substitution it will mostly fail with ELOOP. Some other cases we may be missing (which might be ok) but I think if we will already make exceptions to broaden the checks more we would add /dev/fd & /proc/self/ only as they are the most common. What do you think?

[steadytao]

Ah yeah true, didn't think of those cases. Will broaden a bit. Thank you, Omar.