Simulation Lab 13.1: Module 13 Using Discretionary Access Control

You're staring at the lab instructions. Again. 1. Simulation 13.Module 13. Discretionary Access Control.

And you're wondering — is this just another checkbox exercise, or does it actually matter?

Short answer: it matters. Day to day, not because you'll get graded on it. Practically speaking, they chmod 777 and move on. " And most admins? That said, a lot. They wing it. Because DAC is the access model running on every Linux box, every Windows file server, every NAS your company pretends is "secure enough.Then wonder why the intern can read HR spreadsheets Simple, but easy to overlook. Nothing fancy..

This lab isn't about passing a simulation. It's about building the muscle memory that keeps real systems from leaking.

Let's walk through it like you're sitting next to me at a terminal — not reading a syllabus Took long enough..

What Is Discretionary Access Control (Really)

DAC is the "owner decides" model. That said, that's it. The person who creates a file — or the admin who takes ownership — gets to say who reads, writes, or executes it. No central policy engine. Worth adding: no mandatory labels. Just discretion.

Sound simple? It is. That's the trap.

In Linux, DAC lives in the classic rwx triad: user, group, other. Different syntax. And in Windows, it's NTFS ACLs — Access Control Lists — with explicit Allow/Deny entries per user or group. Same philosophy.

The discretionary part means delegation. Now, she can revoke it Tuesday. On top of that, xlsx. Which means she doesn't need IT approval. That's powerful. Alice creates budget.And she can grant Bob read access. Also dangerous.

Where You'll See It in the Wild

• Linux file servers (chmod, chown, setfacl)
• Windows shared folders (Security tab → Advanced → Effective Access)
• macOS (POSIX + ACL hybrid)
• SMB/CIFS shares mapped to AD groups
• Container volumes mounted with host UID/GID mapping

If you touch permissions — ever — you're doing DAC.

Why This Lab Exists (And Why People Fail It)

Module 13 usually sits mid-course. You've learned users, groups, maybe sudo. Now the course says: *prove you can enforce least privilege using native tools.

The simulation typically drops you into a scenario like:

"User analyst1 needs read access to /project/alpha/reports. User contractor must not see /project/alpha/forecasts. Both are in group project_alpha. Configure permissions accordingly That's the whole idea..

Sounds straightforward. Here's where people crash:

• They chmod 770 on the parent folder and call it done
• They forget contractor inherits group perms unless explicitly denied
• They miss that execute bit on directories = traversal, not "run"
• They test as root and assume it works for everyone

The lab isn't testing if you know chmod. It's testing if you understand inheritance, effective permissions, and the difference between "can't read" and "can't see."

How to Actually Complete Simulation Lab 13.1

Every platform (Practice-Labs, TestOut, Cisco NetAcad, CompTIA CertMaster) skins this differently. But the logic is identical. Here's the workflow that works everywhere.

1. Map the Requirement to a Permission Model

Don't touch the keyboard yet. Write it out:

Now ask: *are these users in the same group?Also, * If yes, standard ugo bits won't cut it. You need ACLs.

2. Check Current State First

Always. Every time.

ls -la /project/alpha/
getfacl /project/alpha/reports
getfacl /project/alpha/forecasts
id analyst1
id contractor

You're looking for:

• Existing ACLs (the + at the end of ls -l output)
• Group memberships
• Current ownership

If analyst1 and contractor share project_alpha as primary group, chmod 770 gives both access. That's the trap.

3. Use ACLs When Groups Overlap

This is the "aha" moment the lab wants you to hit.

# Give analyst1 explicit read on reports
setfacl -m u:analyst1:r-- /project/alpha/reports

# Give analyst1 read/write on forecasts
setfacl -m u:analyst1:rw- /project/alpha/forecasts

# Explicitly deny contractor (optional but clean)
setfacl -m u:contractor:--- /project/alpha/reports
setfacl -m u:contractor:--- /project/alpha/forecasts

Wait — setfacl doesn't support --- syntax on all distros. Better:

# Remove any ACL entry for contractor (falls back to 'other' or group)
setfacl -x u:contractor /project/alpha/reports
setfacl -x u:contractor /project/alpha/forecasts

Then verify:

getfacl /project/alpha/reports
# Should show:
# user:analyst1:r--
# user:contractor:---   (or absent, falling back to 'other')

4. Don't Forget the Execute Bit on Directories

This trips everyone And that's really what it comes down to..

# analyst1 needs to *traverse* to reach files
setfacl -m u:analyst1:r-x /project/alpha
setfacl -m u:analyst1:r-x /project/alpha/reports
setfacl -m u:analyst1:r-x /project/alpha/forecasts

Without x on the directory, read on the file does nothing. You can't cd in. You can't ls. You can't open the file even if you know the name.

5. Test As the Actual User

Not root. Not sudo -u. Switch user.

su - analyst1
cat /project/alpha/reports/q3.pdf   # should work
cat /project/alpha/forecasts/q4.xlsx # should work (if rw)

exit
su - contractor
cat /project/alpha/reports/q3.pdf   # Permission denied
ls /project/alpha/forecasts/        # Permission denied

If it works here — you're done. Screenshot. Here's the thing — submit. Move on.

6. Windows Variant: NTFS ACLs via GUI or icacls

Same logic. Different clicks.

1. Right-click folder → Properties → Security → Advanced
2. Disable inheritance → "Convert inherited permissions into explicit permissions"
3. Remove project_alpha group if it grants too much
4. Add analyst1 → Allow: Read (reports), Modify (forecasts)
5. Add contractor → Deny: List folder / Read data (both folders)
6. Apply → OK → Test with "Effective Access" tab

Pro tip: Deny ACEs order before Allow. But don't over

complicate it with unnecessary Deny entries. A single Allow ACE per user is cleaner and easier to audit Less friction, more output..

icacls "C:\project\alpha\reports" /grant analyst1:R
icacls "C:\project\alpha\forecasts" /grant analyst1:(OI)(CI)M
icacls "C:\project\alpha\reports" /deny contractor:(OI)(CI)R
icacls "C:\project\alpha\forecasts" /deny contractor:(OI)(CI)R

The (OI) (object inherit) and (CI) (container inherit) flags propagate permissions to subfolders and files — equivalent to chmod -R but surgical.

Then verify effective access:

icacls "C:\project\alpha\reports"
icacls "C:\project\alpha\forecasts"

Or use PowerShell for a cleaner view:

Get-Acl "C:\project\alpha\reports" | Format-List
Get-Acl "C:\project\alpha\forecasts" | Format-List

7. Common Pitfalls and How to Avoid Them

Pitfall 1: The "Other" fallback. When you remove an ACL entry with setfacl -x, the user doesn't vanish from the system — they fall back to the other permissions. If other has r-x on the directory, the contractor suddenly regains access. Always check with getfacl after every change.

Pitfall 2: Mask entries. ACLs include an effective mask that caps what even an allowed user can do. If the mask is r--, setting u:analyst1:rw- has no effect — the effective permission becomes r--. Check it:

getfacl /project/alpha/forecasts
# Look for "mask::" line

If the mask is too restrictive, adjust it:

setfacl -m m::rw- /project/alpha/forecasts

Pitfall 3: Assuming sudo proves access. Running sudo cat /project/alpha/reports/q3.pdf as root will always work. It tells you nothing about whether analyst1 can actually reach the file. Always test as the target user.

Pitfall 4: Forgetting default ACLs for new files. If analyst1 creates a file inside /project/alpha/reports, that file inherits permissions based on the directory's default ACL. Without it, new files may fall back to umask and lose access for other authorized users:

setfacl -d -m u:analyst1:rw- /project/alpha/reports
setfacl -d -m u:analyst1:r-x /project/alpha/forecasts

The -d flag sets the default ACL — it applies to all future files and subdirectories created within Simple, but easy to overlook. Still holds up..

Conclusion

File permissions are deceptively simple until they arennt. The chmod 770 shortcut works when permissions map cleanly to groups — but in real environments, users belong to multiple groups, roles overlap, and the "one group fits all" model breaks silently.

ACLs exist precisely for this gap. They let you assign permissions per user, per directory, per file — without forcing you to redesign the entire group structure. On Linux, setfacl and getfacl give you that control. On Windows, icacls and the GUI Security tab do the same job through a different interface.

Some disagree here. Fair enough.

The lab exercise is designed to teach one core lesson: **permissions should reflect the principle of least privilege — grant exactly what each user needs, and nothing more.Practically speaking, ** Whether you achieve that with groups or ACLs is a matter of environment. But understanding both tools, and knowing when to reach for each one, is what separates someone who can manage a filesystem from someone who can secure one.

Screenshot your working configuration. Worth adding: document every setfacl command you ran. When the instructor asks "why," youll have the answer ready.