Linux / Intermediate: system administration reasoning / Lesson 9
Design user and shared-directory access
Combine account identities, supplementary groups, delegated administration, and ACLs without broadening access unnecessarily.
On this page
Lesson goals
- Explain numeric identity and account lookup.
- Design shared-directory inheritance using groups and ACLs.
- Separate authentication, authorization, and administrative delegation.
Account names resolve to numeric identities
File ownership is stored primarily as numeric user and group IDs. Account names make those IDs readable, but moving a disk between machines can map the same number to a different person. getent consults configured account lookup sources, which may include network directories rather than only /etc/passwd. The passwd record contains account metadata; password hashes are normally protected separately. Service accounts should have a defined purpose, minimal permissions, and a reviewed login policy. Do not assume a noninteractive shell alone contains every possible way an account can execute work.
getent passwd learner
id learner
Run only on a disposable image where learner was intentionally created. getent shows the resolved record; id shows its groups. Absence is a valid finding, not a reason to create an account on the host.
Group changes apply to process credentials
A logged-in process holds its credentials, including supplementary group IDs. Editing an account’s group membership does not automatically rewrite every existing session. A fresh login commonly obtains the new list; verify the credentials of the process doing the work. Group-management syntax can replace memberships when an append option was intended, so study the exact distribution command first. The set-group-ID bit on a directory commonly makes new children inherit its group, which helps shared projects, but the creation mode still determines whether teammates receive read or write access.
ACLs add named entries and a mask
An access ACL extends the basic owner/group/other model with named users and groups. The ACL mask limits the effective permissions of named users, named groups, and the owning-group entry; it does not limit the owner entry or other entry. getfacl shows both requested and effective permissions when relevant. A visible group-mode field may reflect the mask rather than only the owning group’s entry. This explains why a later chmod can change effective ACL access even though a named entry still appears to contain rw.
# Study only in a disposable ACL-enabled lab with a learner account.
setfacl -m u:learner:r-- ./shared-note.txt
getfacl ./shared-note.txt
The synthetic file must already belong to the lab operator. Review the mask in getfacl output and verify parent-directory traversal. This is a contextual administration example, not an executable host recipe.
Default ACLs describe future objects
A directory’s default ACL influences the initial access ACL of newly created children. It does not retroactively update existing files. The program’s requested creation mode still limits inherited permissions, so a private file request cannot simply become universally writable through inheritance. Distinguish the directory’s current access ACL from its default ACL. Test the exact application that creates shared files because editors may replace a file through a new temporary object. Document the resulting owner, group, ACL, and effective access instead of trusting a single directory setting.
Delegate narrowly and verify as the real identity
Authentication establishes an identity; authorization decides what it may do. sudo delegates selected privileged actions according to policy, not simply according to who knows a password. A broad command allowance can become broad root access when the program supports shell escapes or arbitrary file writes. Review policy with the supported validation tool on a lab image, and prefer an application-specific role when possible. Test access as the intended account without exposing credentials. Include denied actions in the test plan so a working collaboration setup does not silently allow unrelated access.
Common errors and fixes
New group membership is missing in a session
- Why it happens
- Existing processes retain their earlier credentials.
- How to fix it
- Use a new authorized login and inspect id there.
- Prevent it next time
- Verify the acting process, not only account records.
ACL entry exists but access is denied
- Why it happens
- The mask, a parent directory, or another policy restricts it.
- How to fix it
- Inspect effective getfacl access and the whole path.
- Prevent it next time
- Test the actual identity and operation.
Default ACL expected to change old files
- Why it happens
- Creation inheritance was confused with retroactive editing.
- How to fix it
- Plan a separate reviewed migration for existing objects.
- Prevent it next time
- Separate future defaults from current access inventory.
Check your understanding
1. A named user entry says rw- but the mask says r--. What access is effective?
Show worked solution
Only read is effective for that named user because its permissions are limited by the mask. Changing the owner entry would not repair this named-user restriction. Inspect parent search permissions and any additional policy before concluding the file is reachable.
2. Design tests for a two-person shared project directory.
Show worked solution
Check both identities can create and edit intended shared files, verify new group and ACL inheritance, and test an application’s replacement-save behavior. Confirm an unrelated account cannot read private content. Record expected modes and check existing files separately from newly created files.
Key takeaways
- Numeric identity and current credentials determine access.
- Inspect ACL masks, inheritance, and denied actions.