Security: Metadata restoration applies arbitrary mode bits including setuid/setgid #157

New Issue

2026-07-29T18:34:58+02:00

TapTap commented

2026-07-29 18:34:58 +02:00

Description

file_restore_metadata() in src/shared/metadata.c:96-107 writes the received mode field directly to disk using chmod(path, metadata->mode & 07777). Because metadata->mode comes from the peer, a malicious client can set setuid, setgid, or sticky bits on files created at the destination.

For example, a client could transfer a file with mode 04755 to a path such as ../../../tmp/setuid-sh, giving any user a root shell if the server runs as root. The chown() call at line 100 also uses uid/gid values from the network and is silently ignored on failure.

Location

src/shared/metadata.c:99 — chmod(path, metadata->mode & 07777);
src/shared/metadata.c:100 — chown(path, metadata->uid, metadata->gid); return value discarded.

Suggested fix

Mask the received mode to remove dangerous bits before applying: chmod(path, (metadata->mode & 0777)), or at least strip setuid/setgid unless explicitly allowed by policy.
Do not restore ownership bits from the wire when running as root unless the client is authenticated and authorized.
Check and log chown() failures; consider refusing to apply metadata that cannot be verified.

Severity

High

Category

security

This issue was automatically generated by the issue-creator agent.

## Description `file_restore_metadata()` in `src/shared/metadata.c:96-107` writes the received `mode` field directly to disk using `chmod(path, metadata->mode & 07777)`. Because `metadata->mode` comes from the peer, a malicious client can set setuid, setgid, or sticky bits on files created at the destination. For example, a client could transfer a file with mode `04755` to a path such as `../../../tmp/setuid-sh`, giving any user a root shell if the server runs as root. The `chown()` call at line 100 also uses `uid`/`gid` values from the network and is silently ignored on failure. ## Location - `src/shared/metadata.c:99` — `chmod(path, metadata->mode & 07777);` - `src/shared/metadata.c:100` — `chown(path, metadata->uid, metadata->gid);` return value discarded. ## Suggested fix 1. Mask the received mode to remove dangerous bits before applying: `chmod(path, (metadata->mode & 0777))`, or at least strip setuid/setgid unless explicitly allowed by policy. 2. Do not restore ownership bits from the wire when running as root unless the client is authenticated and authorized. 3. Check and log `chown()` failures; consider refusing to apply metadata that cannot be verified. ## Severity High ## Category security --- _This issue was automatically generated by the issue-creator agent._

TapTap added the bug security needs-triage labels 2026-07-29 18:34:58 +02:00

TapTap referenced this issue from a commit

2026-07-29 18:52:09 +02:00

fix: resolve all security issues (#154, #156, #157, #159, #160, #161, #162, #170)

TapTap referenced this issue

2026-07-29 18:52:26 +02:00

fix: resolve all security issues (#154, #156, #157, #159, #160, #161, #162, #170) #172

TapTap referenced this issue

2026-07-29 19:29:55 +02:00

Comprehensive fix: security, bugs, refactoring, tests, and rsync parity features #173

TapTap closed this issue

2026-07-30 18:17:30 +02:00