Permissions · XB Field Notes

Umask filters new permissions, with a default ACL exception

Sat, 09 Oct 2027 00:00:00 +0000

A process’s umask removes permission bits when creating files and directories under the ordinary mode-based creation rule. The application first supplies a requested mode; the mask restricts that request. It is neither a complete access policy nor an instruction to rewrite existing files. A directory’s default access control list changes the creation calculation, so inspecting only the process mask can give an incomplete prediction.

When it breaks

Without a default ACL, the ordinary permission result is the requested mode bitwise AND the complement of umask. For requested 0666 and mask 0022, that gives 0644. This is not arithmetic subtraction. A request for 0600 remains 0600 under the same mask, and a request that omits execute permission does not acquire it because the mask is permissive.

A restrictive umask does not repair an existing world-writable file. Opening and truncating that file changes content while preserving its existing mode. A later chmod can also widen permissions regardless of the current mask. Treating umask as a permanent upper bound on permissions therefore leaves both existing-file and subsequent-permission-change cases unaccounted for.

When the parent directory supplies a default ACL, Linux derives the new access ACL from that default and restricts it by the application’s requested mode; the process umask is not applied in the ordinary way. A shared directory can consequently produce group-accessible files even when the creator’s mask is 0077. The inherited ACL must be part of the diagnosis.

Check it quickly

Save this as mask.py and run python3 mask.py on Linux with Python 3 and setfacl installed. The temporary-file directory must support default ACLs. The recorded run used Python 3.11.2, acl 2.3.1, and a separate ext4 volume selected through TMPDIR. The initial tmpfs environment rejected default ACLs, so the complete experiment was rerun on ext4:

from pathlib import Path
from tempfile import TemporaryDirectory
import os,stat,subprocess

def create(path,requested):
 fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,requested);os.close(fd)
def mode(path):return stat.S_IMODE(path.stat().st_mode)
previous=os.umask(0o022)
try:
 with TemporaryDirectory(prefix='xbcatm-umask-') as directory:
 root=Path(directory)
 data=root/'data';create(data,0o666);assert mode(data)==0o644
 executable=root/'executable';create(executable,0o777);assert mode(executable)==0o755
 private=root/'private';create(private,0o600);assert mode(private)==0o600
 folder=root/'folder';folder.mkdir(mode=0o777);assert mode(folder)==0o755
 assert 0o600&~0o022==0o600 and 0o600-0o022!=0o600
 print('without default ACL: requested mode AND NOT umask; 0666 becomes 0644, 0777 becomes 0755')
 os.umask(0o077)
 strict=root/'strict';create(strict,0o666);assert mode(strict)==0o600
 existing=root/'existing';create(existing,0o666);existing.chmod(0o666)
 fd=os.open(existing,os.O_WRONLY|os.O_TRUNC);os.close(fd)
 assert mode(existing)==0o666
 print('restrictive mask leaves an existing 0666 file unchanged; chmod can widen permissions later')
 acl_folder=root/'acl';acl_folder.mkdir()
 subprocess.run(['setfacl','-d','-m','u::rwx,g::rwx,o::---',str(acl_folder)],check=True)
 inherited=acl_folder/'inherited';create(inherited,0o666)
 restricted=acl_folder/'restricted';create(restricted,0o600)
 assert mode(inherited)==0o660 and mode(restricted)==0o600
 print('with default ACL and umask 0077: request 0666 yields 0660; request 0600 still yields 0600')
 status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
 assert int(status['Umask'].strip(),8)==0o077
 print('/proc/self/status observes this process mask without temporarily changing it')
finally:os.umask(previous)

With mask 0022 and no inherited default ACL, requesting 0666 produces a 0644 file. Requesting 0777 produces 0755 for both a regular file and a directory, while requesting 0600 still produces 0600. The fixture also checks that arithmetic subtraction would give a different result for the restrictive request, exposing that common calculation error.

After switching to mask 0077, a newly created file requested as 0666 becomes 0600. Another file is explicitly changed to 0666, then opened with truncation but without creation. Its mode stays 0666. This comparison distinguishes initial creation from later operations on an existing inode, rather than assuming every open reapplies creation policy.

Next, the fixture installs a default ACL granting the owning user and group full permissions and granting others none. Under the still-active 0077 mask, a new file requested as 0666 receives mode 0660. The inherited ACL preserves group read/write permissions despite the restrictive mask, but the application’s request excludes execute permission.

A neighboring file requested as 0600 remains 0600 under that same default ACL. The default does not invent permissions absent from the requested mode. These two requests establish both the default-ACL exception to ordinary masking and the continued role of the application’s explicit creation request.

The script reads Umask from /proc/self/status and confirms that the process mask is still 0077. It restores the original mask in finally and removes the temporary tree. If the selected filesystem cannot install the ACL, the command fails; skipping that step would leave the central exception untested.

Apply creation policy at the right layer

Umask is inherited through normal process creation and preserved across execution of another program. Set it in the actual launch path for a service or command. An unrelated terminal’s mask does not retroactively change the state of an already running process, and shell startup files matter only when the launch path reads them.

Because umask is process-wide for threads sharing the relevant filesystem state, temporarily changing it to discover its previous value can interfere with concurrent file creation. On Linux, reading the proc status field avoids that mutation. Applications needing a specific private file should request suitably restrictive permissions and verify their actual storage context.

Inspect parent-directory access, ownership, ACLs, and the resulting file permissions together. A 0660 file inside an inaccessible parent is not automatically reachable by its group, and mode bits alone do not describe all named ACL entries. The experiment proves creation results; end-to-end access requires testing the intended identity through the complete path.

Sources

umask(2), creation masks, inheritance, default ACL interaction, and proc inspection, checked 2026-09-12.
acl(5), default ACL inheritance and requested-mode permission restrictions, checked 2026-09-12.
open(2), creation modes and opening or truncating an existing file, checked 2026-09-12.

Setuid runs as the file owner

Sat, 02 Oct 2027 00:00:00 +0000

A setuid binary runs with the identity of its owner rather than of whoever started it. The kernel swaps credentials at exec time, which is how passwd rewrites /etc/shadow without an ordinary user holding write permission on it. The bit belongs to the file, and it grants the owner’s entire identity, not one narrow ability.

That is an odd trade to make on purpose: a whole program is trusted with an entire account, so any bug inside it is a privilege bug. Capabilities, user namespaces and socket activation now cover most of what setuid was for.

Identity follows the file

execve(2) states the rule directly: if the set-user-ID bit is set on the program file, the effective user ID of the calling process becomes that of the file’s owner. The real UID and real GID are unchanged, and the new effective UID is copied into the saved set-user-ID. Real, effective and saved are the whole mechanism.

The bits are visible before anything runs: stat reports /usr/bin/sudo as mode 4511 (-r-s--x--x) and /usr/bin/su as 4755, both owned by uid 0, while /usr/bin/passwd is plain 0755. Which binaries carry the bit is a per-host fact, so read it rather than assume it.

Four ways the bit does nothing

execve(2) lists the conditions under which the transition is skipped: no_new_privs is set on the calling thread, the filesystem is mounted nosuid, or the process is being ptraced. For a nosuid mount the man page warns that behaviour varies by kernel version — some refuse the exec with EPERM, others ignore the bits and run the file anyway. File capabilities are ignored under those same conditions.

Scripts are the fourth case: “Linux (like most other modern UNIX systems) ignores the set-user-ID and set-group-ID bits on scripts.” A shell script can list as -rwsr-xr-x forever and elevate nothing, because #! hands control to the interpreter and only the interpreter’s own bits count. On the macOS host here, chmod 4755 as owner returned EPERM while chmod 1755 set the sticky bit.

Dropping privilege is not symmetric

The setuid(2) syscall is not the file bit. A privileged caller holding CAP_SETUID moves real, effective and saved together, so a set-user-ID-root program calling setuid(1000) ends with all three at 1000 — and regaining root then fails with EPERM, because 0 is no longer the real UID or the saved set-user-ID. The man page says such a program must use seteuid(2) instead.

seteuid(2) moves the effective UID alone, and an unprivileged caller may only target the real UID, the effective UID, or the saved set-user-ID. The saved UID is therefore a deliberate escape hatch: the same process can drop to 1000 with seteuid and climb back to 0 afterwards. Permanent drops need setuid(2); reversible ones need seteuid(2).

The narrower replacements

Capabilities split one identity into about forty named powers. setcap cap_net_bind_service=+ep /usr/bin/webserver lets that binary bind port 80 with no setuid bit and no ability to read /etc/shadow. capabilities(7) notes that exec of a set-user-ID-root program still results in the full capability set being treated as enabled — exactly the blast radius the narrower grant avoids. User namespaces map uid 0 to the caller inside a namespace and grant nothing outside it, and socket activation keeps the listener owned by PID 1 while the service runs unprivileged.

When it breaks

The classic failure is the setuid script: someone rewrites a helper in shell or Python, keeps the mode, and the tool silently loses the privilege it needed. The listing still shows s, an audit still flags it, and nothing elevates. Prove elevation with id -u printed from inside the running program, never from the mode string.

The dangerous failure is a shell escape inside a setuid binary. The C library scrubs LD_PRELOAD and its relatives, but application-level inputs stay yours to sanitise: an unscrubbed PATH turns system("thumbnail ...") into an attacker’s binary, and a user-controlled config path redirects file reads. Because the whole process carries the owner’s identity, one such bug is a root hole. Keep the list short and give each binary an owner that owns nothing else of value.

Check it quickly

Run these on the host you are auditing:

find / -xdev -perm -4000 -type f -printf '%m %u %p\n' 2>/dev/null
findmnt -no TARGET,OPTIONS / /home /tmp /var | grep -o nosuid
getcap -r /usr/bin /usr/sbin 2>/dev/null
grep -E 'NoNewPrivs|CapEff' /proc/self/status
stat -c '%A %a %U %n' /usr/bin/passwd

The first command should return a short list; on a stock Debian host it is roughly a dozen paths, and every one should be a program you would trust with its owner’s whole identity. A nosuid on a filesystem holding a setuid binary explains a privilege that vanished, and anything in the getcap output has already migrated off setuid.

Sources

man7: execve, the set-user-ID transition at exec and the four conditions that skip it, checked 2026-09-16.
man7: setuid, CAP_SETUID, the saved set-user-ID, and why seteuid is the reversible path, checked 2026-09-16.
man7: capabilities, narrow capability grants as the replacement for a setuid-root binary, checked 2026-09-16.

The sticky bit restricts removal in a shared directory

Fri, 01 Oct 2027 00:00:00 +0000

The sticky bit on a Linux directory adds an ownership restriction to removing or renaming entries. It is commonly combined with broad directory write and search permissions so several users can create temporary files without freely removing one another’s entries. The directory permission check and the sticky ownership check both matter; sticky is an additional condition, not a replacement for normal access control.

When it breaks

Without sticky, a user with the necessary write and search permissions on a directory can often remove another user’s file even when that file’s mode grants no access. Unlink changes the directory’s name-to-object relationship. It does not require permission to read or overwrite the file contents, so making the file itself mode 000 does not protect its pathname in a broadly writable directory.

With sticky enabled, ordinary users must additionally own the entry or the containing directory to perform the relevant removal. A privileged process with the appropriate CAP_FOWNER capability can bypass that ownership restriction. Sticky therefore limits peers under a specific permissions model; it does not protect against every administrator or the directory’s own owner.

Sticky does not stop permitted content access. Another user may still read or overwrite a mode-0666 file while being unable to unlink it. The mode also does not automatically propagate to newly created subdirectories. Confusing pathname protection, content privacy, and inheritance can leave a shared tree with materially different behavior from its apparently protected top level.

Check it quickly

Save this as sticky.py and run python3 sticky.py as root in a disposable Linux container. The controller needs permission to assign three numeric identities and launch unprivileged children; it creates no accounts. The recorded environment used Linux 6.12.76 and Python 3.11.2. All paths are inside a temporary fixture directory:

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,stat,subprocess,sys

directory_owner=61000;file_owner=61001;other_user=61002
probe_code=r'''
import os,sys
path=sys.argv[1];operation=sys.argv[2]
try:
 if operation=='unlink':os.unlink(path)
 elif operation=='rename':os.rename(path,path+'-renamed')
 elif operation=='write':
 fd=os.open(path,os.O_WRONLY|os.O_TRUNC)
 try:os.write(fd,b'other-user-write')
 finally:os.close(fd)
 elif operation=='read':
 fd=os.open(path,os.O_RDONLY);os.close(fd)
 elif operation=='mkdir':os.mkdir(path,0o777)
 else:raise AssertionError('unknown operation')
except OSError as error:print(error.errno)
else:print(0)
'''
def probe(uid,path,operation):
 result=subprocess.run([sys.executable,'-c',probe_code,str(path),operation],user=uid,group=uid,extra_groups=[],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 return int(result.stdout)
with TemporaryDirectory(prefix='xbcatm-sticky-') as directory:
 root=Path(directory);root.chmod(0o755);shared=root/'shared';shared.mkdir();shared.chmod(0o777)
 os.chown(shared,directory_owner,directory_owner);victim=shared/'victim'
 def make_victim(mode):
 victim.write_bytes(b'fixture');os.chown(victim,file_owner,file_owner);victim.chmod(mode)
 make_victim(0o000)
 assert probe(other_user,victim,'unlink')==0
 print('without sticky, directory write/search allows removing another owner’s mode-000 file')
 shared.chmod(0o1777);make_victim(0o666)
 assert probe(other_user,victim,'unlink')==errno.EPERM
 assert probe(other_user,victim,'rename')==errno.EPERM
 assert probe(other_user,victim,'write')==0 and victim.read_bytes()==b'other-user-write'
 victim.chmod(0o600);assert probe(other_user,victim,'read')==errno.EACCES
 print('sticky blocks outsider unlink/rename, but file permissions still govern reading and writing')
 assert probe(file_owner,victim,'unlink')==0
 make_victim(0o600);assert probe(directory_owner,victim,'unlink')==0
 print('both the entry owner and the directory owner may remove it')
 child=shared/'child';assert probe(other_user,child,'mkdir')==0
 assert not child.stat().st_mode&stat.S_ISVTX
 shared.chmod(0o1766);assert stat.filemode(shared.stat().st_mode).endswith('T')
 assert probe(other_user,shared/'blocked','mkdir')==errno.EACCES
 shared.chmod(0o1777);assert stat.filemode(shared.stat().st_mode).endswith('t')
 print('sticky is not inherited by a new subdirectory; uppercase T means other-execute is absent')

The first case uses a 0777 directory owned by one identity and a mode-000 file owned by another. A third user successfully unlinks that file. This demonstrates that directory write/search permissions can allow removal independently of the file’s content permissions. Root sets up the fixture, but the tested removal occurs under the third, unprivileged identity.

After setting the directory to 1777, the third user’s unlink and rename attempts fail with EPERM. The same user successfully overwrites the file when its mode is 0666. The write opens an existing file without O_CREAT, avoiding a different Linux protected-regular-file policy that could otherwise obscure which permission rule the exercise is measuring.

Changing the file to 0600 causes the third user’s read attempt to fail with EACCES. Sticky remained enabled throughout, so it is the file-permission change that altered content access. The two error classes arise from different checks and should not be collapsed into a claim that sticky makes each temporary file private.

The file’s owner successfully removes its entry, and a newly recreated file can also be removed by the directory owner. Both outcomes are checked using ordinary child identities. These cases demonstrate the two ownership exceptions directly instead of relying on root, whose capabilities would make the result ambiguous.

Next, the third user creates a subdirectory. It has no sticky bit automatically inherited from the parent. Changing the parent to 1766 produces an uppercase T in its permission display, and another creation attempt fails because directory search permission is missing. Restoring 1777 produces lowercase t, which combines sticky with the other-execute bit.

Design shared storage deliberately

Use sticky when the intended policy allows shared creation but restricts peer removal. Set file permissions or ACLs separately for the intended readers and writers. If each user’s data must remain confidential, verify access under another identity; the presence of a sticky directory alone supplies no evidence that its files are unreadable.

Treat directory ownership as authority over its entries. A directory owner who can remove files may disrupt other users even while unable to read their contents. In a hierarchy, inspect the permissions of the actual parent containing each entry, because a protected ancestor does not automatically apply its sticky behavior to descendants.

For temporary-file creation, use an API that creates a fresh, suitably restricted object without trusting a predictable preexisting name. Sticky helps with a particular shared-directory removal problem, but it does not solve symbolic-link substitution or every unsafe open pattern. Verify creation, subsequent content access, and cleanup under the actual identities and filesystem used by the application.

Sources

inode(7), sticky directories, file ownership, and displayed permission bits, checked 2026-09-12.
unlink(2), directory write/search permissions and sticky removal restrictions, checked 2026-09-12.
capabilities(7), CAP_FOWNER exceptions to sticky-directory ownership checks, checked 2026-09-12.
rename(2), rename permission checks in sticky directories, checked 2026-09-12.