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.
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._
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
file_restore_metadata()insrc/shared/metadata.c:96-107writes the receivedmodefield directly to disk usingchmod(path, metadata->mode & 07777). Becausemetadata->modecomes 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
04755to a path such as../../../tmp/setuid-sh, giving any user a root shell if the server runs as root. Thechown()call at line 100 also usesuid/gidvalues 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
chmod(path, (metadata->mode & 0777)), or at least strip setuid/setgid unless explicitly allowed by policy.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.