Directory creation mode handling silently drops setuid/setgid bits

[zerodaybugs]

Version

uutils/coreutils HEAD c61b881 tested on 2026-06-07.

Summary

mkdir -m with a mode containing setuid or setgid silently creates a directory without those bits. GNU mkdir sets them. This is a correctness / GNU-compatibility issue, not a security advisory: the behavior is fail-safe because uutils grants fewer permissions than requested.

Reproduction

coreutils mkdir -m 2775 shared && stat -c %a shared
# uutils observed: 755

/usr/bin/mkdir -m 2775 shared && stat -c %a shared
# GNU observed: 2775

Matrix:

-m 2755 : uutils=755   GNU=2755
-m 4755 : uutils=755   GNU=4755
-m 6755 : uutils=755   GNU=6755
-m 3755 : uutils=1755  GNU=3755
-m 7755 : uutils=1755  GNU=7755
-m 1755 : uutils=1755  GNU=1755

The sticky-only control matches, isolating the gap to missing post-create chmod for setuid/setgid bits.

Cause

create_dir_with_mode() relies on DirBuilder::mode(), i.e. mkdir(2). Linux mkdir(2) honors sticky but ignores setuid/setgid for directories. GNU compensates with a post-create chmod; uutils does not.

Impact

Correctness / compatibility regression. A common practical failure is mkdir -m 2775 /shared, which silently produces a non-setgid directory, breaking group-shared directory workflows.

Suggested fix

After create, if mode & 0o6000 != 0, apply a post-create chmod for the special bits, matching GNU behavior.

[Touchebag]

As far as I can tell this seems to be a general issue, not just limited to with -m.

[zerodaybugs]

Thanks, that makes sense.

I scoped the initial report to mkdir -m because that was the deterministic user-facing trigger I tested, but I agree the underlying issue appears more general than the -m option itself.

The pattern I observed is:

• requested modes containing S_ISUID / S_ISGID are silently created without those bits;
• sticky-only mode is preserved;
• GNU applies the requested special bits after directory creation, while uutils appears to rely on the initial directory creation mode and does not apply a post-create chmod for 0o6000.

So a broader title may be more accurate, for example:

Directory creation mode handling silently drops setuid/setgid bits

or:

Directory creation paths do not preserve requested setuid/setgid bits

I kept the original issue framed as correctness / GNU compatibility, not as a security advisory, because the behavior is fail-safe: uutils grants fewer permissions than requested.

I can add a broader test matrix for other directory-creating paths if useful.