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.

Ordinary masking and default ACL inheritance are separate creation branches. Existing-file truncation and later chmod are separate; the cases are fixture expectations.

Check it quickly

Save this as mask.py and run python3 mask.py on Linux with Python 3 and setfacl installed. Use an authorized temporary-file base without a preexisting default ACL, on a filesystem supporting default ACLs; enable assertions. The article reports Python 3.11.2/acl 2.3.1 on ext4 after an initial tmpfs rejection, but raw logs were not recovered and this review made no storage changes or rerun. That rejection does not characterize every tmpfs configuration:

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. Its cleanup attempts to restore the original mask and remove the temporary tree; interruption is not a verified cleanup. 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 changes effective identity at exec

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

Setuid on a Linux executable can change the process’s effective user ID to the file owner’s ID when exec succeeds. It does not replace every credential with the owner’s login identity. A privileged helper can therefore perform a controlled operation on another account’s behalf, but its input handling and privilege lifetime become part of the security boundary. The mode bit alone proves neither that a transition occurred nor that the helper is safe.

Distinguish the file bit from process credentials

The usual set-user-ID transition changes the effective UID, then copies it into the saved set-user-ID. The real UID remains unchanged. Group credentials are separate: setuid does not automatically install the file owner’s supplementary groups. Linux also has filesystem IDs and capability sets, so real, effective and saved UIDs are useful observations rather than a complete description of authority.

Inspect the deployed file instead of assuming a distribution-wide mode. A privileged password-changing program might be installed differently in a container or customized image. A lowercase s in the owner-execute position indicates both setuid and owner execute; uppercase S indicates setuid without that execute bit. Neither display substitutes for checking ownership, the actual executable, and the process context in which it will run.

Execution can suppress the transition

Linux documents no_new_privs, nosuid mounts and tracing as conditions that suppress the privilege transition; some documented combinations can fail execution instead. File capabilities also have execution constraints. Do not disable one of these protections merely to make a demonstration work. Establish which policy applies to the target path and process, and report the resulting limitation.

Linux ignores set-user-ID and set-group-ID bits on interpreter scripts. Moving a helper from a native executable to a script while preserving its mode therefore does not preserve elevation behavior. Making a general-purpose interpreter privileged is not a safe substitute. Another executable launched by a privileged program may deliberately drop credentials, so running a separate id command is not necessarily a faithful observation of the original helper’s credentials.

Privilege dropping needs a complete design

The setuid system call is distinct from the executable’s mode bit. A sufficiently privileged caller can change real, effective and saved UIDs; an unprivileged caller has a narrower set of permitted transitions. Seteuid can support a reversible effective-UID change when a permitted saved identity remains available. Always check the syscall’s return value before assuming the intended state was reached.

Removing a saved UID is only part of permanent privilege removal. Supplementary groups, retained capabilities, open privileged descriptors, namespaces and later execution paths also matter. A single setuid call is not a universal privilege-drop recipe. The required sequence depends on the program’s existing credentials and resources; security-sensitive helpers need design review rather than a copied one-line pattern.

When it breaks

A mode listing with an s can mask a suppressed transition, while an overly broad helper can expose real authority through unsafe path lookup or user-selected configuration. Loader protections restrict dangerous environment variables in secure-execution mode, but they do not validate the application’s inputs. Avoid shell-based command construction and define exactly which files, arguments and operations the helper may use.

Capabilities can narrow a particular grant, such as permission to bind privileged ports, without making every other permission disappear. Existing user access and other capabilities still apply, and capability bounding and securebits rules qualify root behavior. Likewise, namespace-local root is not host root, but mapped ordinary-user permissions remain meaningful. Socket activation can supply an already-open listener; it does not remove the need to secure the service handling it.

Setuid affects selected exec-time credentials under documented guards. The retained inspection does not execute the target or prove elevation; current runtime remains held.

Check it quickly

On Linux with Bash, GNU stat, util-linux findmnt, libcap getcap and Python 3, run the complete block below. It reads one installed file and the new Python process’s own credential status. It never executes passwd, changes permissions, changes credentials, mounts anything or creates a namespace. The explicit pathname avoids a helper search, but separate metadata reads do not atomically bind a later execution to the same file. This review did not run the inspection; assertions require a trusted test environment.

BASH_ENV= bash --noprofile --norc <<'BASH'
set -eu
target=/usr/bin/passwd
test -f "$target"
stat -c 'mode=%A numeric=%a owner=%u group=%g path=%n' "$target"
findmnt --noheadings --output TARGET,VFS-OPTIONS --target "$target"
getcap -v "$target"
python3 - <<'PYTHON'
import os
from pathlib import Path

status = dict(line.split(':', 1) for line in
 Path('/proc/self/status').read_text().splitlines() if ':' in line)
uids = tuple(map(int, status['Uid'].split()))
gids = tuple(map(int, status['Gid'].split()))
assert uids[:3] == os.getresuid()
assert gids[:3] == os.getresgid()
assert len(uids) == len(gids) == 4
for key in ['Uid', 'Gid', 'Groups', 'NoNewPrivs', 'CapEff', 'CapBnd']:
 print(f'{key}:{status[key]}')
print('PASS: inspected metadata and current credentials; target not executed')
PYTHON
BASH

Expect the actual mode and numeric ownership, the filesystem’s mount options, and the target’s capability listing. An empty capability set does not prove absence of the setuid bit, and a setuid bit does not imply a file capability. The Python assertions compare the first three UID and GID fields with the corresponding system-call results; the fourth fields are filesystem IDs.

The PASS line establishes this read-only inspection only. Values vary by host, and no expected root identity is hardcoded. This exercise does not demonstrate elevation, irreversible dropping, or exploit resistance. Those require a separately authorized disposable security test and observations inside the actual helper, without weakening the host’s protections.

Sources

Linux execve, effective-ID changes, unchanged credentials and suppression conditions, checked 2026-10-15.
Linux credentials, supplementary groups and filesystem IDs, checked 2026-10-15.
Linux setuid, privileged and unprivileged transitions and required error checking, checked 2026-10-15.
Linux seteuid, permitted effective-ID transitions, checked 2026-10-15.
Linux capabilities, capability limits and credential interactions, checked 2026-10-15.
Linux dynamic linker, secure-execution environment restrictions, checked 2026-10-15.
Linux proc_pid_status, credential and capability status fields, checked 2026-10-15.

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.

Sticky restricts entry removal, with ownership and capability exceptions. File modes separately govern content; fixture outcomes are expected, not newly observed.

Check it quickly

Save as sticky.py and run python3 sticky.py only in an authorized disposable Linux environment with enabled assertions. The controller needs root privileges to assign three numeric identities and launch ordinary children; it creates no accounts. The article reports Linux 6.12.76/Python 3.11.2, but no raw logs were recovered and this review did not rerun it. Filesystem ownership, UID mappings and child capabilities must match the intended permission model:

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.

The fixture expects EPERM for the third user’s unlink and same-directory rename under 1777; the manual also permits EACCES for sticky restrictions. 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.