Change a writable account or privilege-policy file

Needs: Effective write/replace permission, known file syntax and a useful identity/policy consumer; preserve the original

Shell commands

# Baseline
ls -l /etc/passwd /etc/shadow /etc/sudoers
namei -l /etc/passwd
getfacl -p /etc/passwd 2>/dev/null

# Writable /etc/passwd — authorized disposable lab only
cp /etc/passwd /tmp/passwd.backup
HASH=$(openssl passwd -6 'TEMP_PASSWORD')
printf 'root2:%s:0:0:root:/root:/bin/bash\n' "$HASH" >> /etc/passwd
su - root2
id

Verify → Verify the resulting identity/authorized action and retain the exact change plus recovery copy privately.

If it fails → Read-only mounts, PAM behavior or syntax mistakes can defeat the candidate. Prefer a narrower reversible consumer when available. More detail ↓

If → then

A new Linux foothold or an identity/privilege change → Establish Linux state and choose an escalation candidate
Needs: A working command channel and accurate effective identity, group, mount and process context
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
A root-consumed file or directory appears writable → Prove effective file, directory, ACL and mount control
Needs: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Change a writable account or privilege-policy file

USE WHEN: Account metadata or a privilege-policy file appears writable
STARTING ACCESS: A verified Linux foothold with a known effective UID, groups and filesystem context
RESULT: A verified account or policy-backed privilege transition

Recognize the clue

Check permissions on the account/policy file identified by enumeration, including parents and mount state, before any content change.

stat /etc/passwd /etc/shadow /etc/sudoers
getfacl -p /etc/passwd /etc/sudoers 2>/dev/null

SYNTHETIC EXAMPLE OUTPUT

/etc/passwd: mode=0666 owner=root
Effective write for current identity: present

Means: A sensitive account file appears writable; the authentication implementation and valid record syntax determine its effect.

Confirm: Preserve original state; confirm exact effective write, file consumer, useful identity and recovery/trigger.

After validation: The valid authorized change produces the intended authentication/policy effect: choose this sensitive-file route.
Ruled out in this context: The filesystem/ACL denies the required operation: reject the writable-file hypothesis.
Still inconclusive: Mode bits without ACL/mount/consumer evidence leave a safe usable transition unresolved.

Troubleshooting: Read-only mounts, PAM behavior or syntax mistakes can defeat the candidate. Prefer a narrower reversible consumer when available.

Writable /etc/passwd — authorized disposable lab only

Preserve a known-good copy and restore it. UID/GID 0 creates a superuser. Do not risk corrupting a host when no safe recovery exists.

Also inspect effective access to /etc/sudoers.d, PAM, SSH authorized-key locations and root-executed startup/configuration files.

Why it works

Sensitive-file write can change authentication or authorization, but the exact file format and consuming implementation determine the effect. A malformed account/policy file can break access.

Worked example · hypothetical

Observation: a disposable lab exposes writable account metadata. Test: preserve the original and inspect the authentication implementation before the documented minimal change. Illustrative output: the new context authenticates with the expected UID. Interpretation: verify and restore according to the lab objective.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗