Files · XB Field Notes

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.

File descriptors name a process’s open references

Sun, 21 Feb 2027 00:00:00 +0000

A file descriptor is a small integer used within one process to refer to an open resource. The process’s descriptor table maps that number to an open file description maintained by the kernel. For a regular file, the description includes the current offset and file status flags. Another process can use the same integer for a completely different resource, so the number alone is not a global file identity.

When it breaks

dup allocates another descriptor referring to the same open file description; it does not simply copy the integer or reopen the pathname. Reads through the two descriptors therefore share a regular file’s offset. By contrast, opening the same pathname again normally creates another description with its own offset. Equal device/inode identity does not imply equal open-description state.

Status flags and descriptor flags also live at different levels. An F_SETFL change to a shared open description is visible through duplicated references. The close-on-exec flag belongs to each descriptor separately. Confusing these layers can change another consumer’s behavior or unintentionally expose a descriptor to a subsequently executed program.

Closing a descriptor releases that table entry, and its integer can immediately be reused. Code retaining only a stale number may then operate on a new resource instead of reliably receiving a bad-descriptor error. Ownership and lifetime rules are essential when descriptors pass between callbacks, threads, or libraries; checking that an integer is nonnegative is not sufficient validation.

Check it quickly

Run this Python script in a disposable Linux environment. It creates two harmless temporary files and closes every descriptor it opens. The recorded environment used Linux 6.12.76 with Python 3.11.2. The exercise runs without background threads so allocation and reuse can be inspected without another thread racing to consume the released descriptor number:

from pathlib import Path
from tempfile import TemporaryDirectory
import fcntl,os

with TemporaryDirectory(prefix='xbcatm-fds-') as directory:
 root=Path(directory);original=root/'original';other=root/'other'
 original.write_bytes(b'abcdef');other.write_bytes(b'replacement')
 handles=set()
 try:
 first=os.open(original,os.O_RDONLY);handles.add(first)
 duplicate=os.dup(first);handles.add(duplicate)
 independent=os.open(original,os.O_RDONLY);handles.add(independent)
 assert first!=duplicate
 assert os.read(first,2)==b'ab' and os.read(duplicate,2)==b'cd'
 assert os.read(independent,2)==b'ab'
 assert os.lseek(first,0,os.SEEK_CUR)==4
 print('dup uses a different descriptor but shares offset; a separate open has its own offset')
 flags=fcntl.fcntl(duplicate,fcntl.F_GETFL)
 fcntl.fcntl(duplicate,fcntl.F_SETFL,flags|os.O_NONBLOCK)
 assert fcntl.fcntl(first,fcntl.F_GETFL)&os.O_NONBLOCK
 assert not fcntl.fcntl(independent,fcntl.F_GETFL)&os.O_NONBLOCK
 os.set_inheritable(first,False);os.set_inheritable(duplicate,True)
 assert not os.get_inheritable(first) and os.get_inheritable(duplicate)
 print('file status flags shared by dup; close-on-exec flags remain descriptor-specific')
 os.close(first);handles.remove(first)
 reused=os.open(other,os.O_RDONLY);handles.add(reused)
 assert reused==first and os.read(first,32)==b'replacement'
 assert os.read(duplicate,2)==b'ef'
 print('closed descriptor number is reused for another file; surviving duplicate still reads original')
 original.unlink();os.lseek(duplicate,0,os.SEEK_SET)
 assert os.fstat(duplicate).st_nlink==0 and os.read(duplicate,32)==b'abcdef'
 print('unlink removes the pathname while an open descriptor retains access')
 finally:
 for handle in handles:os.close(handle)

The first open reads ab, and its duplicate then reads cd. Both now observe offset four. A separate open of the same file still reads ab from its own initial position. These exact bytes establish which state is shared; merely seeing that both paths contain the same data would not distinguish duplicated references from independent opens.

The script sets O_NONBLOCK through the duplicate and observes the flag through the first descriptor, while the independent open retains its previous flags. For this regular-file fixture, the test concerns flag ownership, not a claim that ordinary disk reads become asynchronous. It then gives the duplicate a different inheritable setting and confirms that the original descriptor’s close-on-exec behavior is unchanged.

After the first descriptor closes, opening the other file reuses that integer. Reading through the stale variable now returns replacement, while the surviving duplicate still reads the original file’s final ef. This is a concrete demonstration of why a closed integer is not a durable reference to an object that used to exist.

Unlinking the original pathname removes its directory entry. The duplicate’s file status reports link count zero, yet seeking and reading through it still returns abcdef. Other open references in the fixture also remain valid until closed. Removing a name, closing one descriptor, and releasing the final open reference are distinct operations.

The script keeps an explicit set of currently owned descriptors for cleanup, removing the closed entry before its number is reused. That avoids accidentally treating the reused integer as two separately owned handles. Real code needs the same clarity when a function transfers ownership or a wrapper is responsible for closing its underlying descriptor.

Define ownership at the handoff

Document whether a function borrows a descriptor or takes responsibility for closing it. Use scoped wrappers where their ownership model fits, and avoid having two independent owners both close the same integer. Duplicating a reference can separate descriptor lifetime, but it still shares open-description state unless a genuinely independent open is intended.

Choose inheritance explicitly when starting another program. Language runtimes may create descriptors as non-inheritable, and subprocess APIs may close all except an allowed set. Verify the actual launch behavior rather than assuming that fork, exec, and a high-level process API expose identical descriptors.

Finally, match operations to the resource type. A pipe or socket is addressed through a descriptor too, but it does not acquire a regular file’s seekable offset contract. Correct descriptor handling combines resource semantics, open-description state, and a clear rule for who may close each process-local handle.

Sources

open(2), process descriptor tables, open file descriptions, offsets, and flags, checked 2026-09-12.
dup(2), new descriptor allocation, shared descriptions, and descriptor flags, checked 2026-09-12.
unlink(2), removing names while open references retain the file, checked 2026-09-12.