Manage users and groups →mediumMultiple ChoiceObjective-mapped

EX200 Manage users and groups Practice Question

Exhibit

Refer to the exhibit.

$ id user1
uid=1000(user1) gid=1000(user1) groups=1000(user1),10(wheel)

A user was recently added to the 'testgrp' group using `usermod -aG testgrp user1`. However, when they try to access a file owned by testgrp with permissions 660, they get permission denied. What is the most likely reason?

⚠ Common exam trap

Many exam-takers assume `usermod -aG` immediately grants access, overlooking that group membership changes require a new login session to take effect in the process's credential cache.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The user did not log out and log back in.

When a user is added to a supplementary group with `usermod -aG`, the group membership change does not take effect in the user's current login session. The user must log out and log back in (or start a new login shell) for the new group to be recognized by the kernel's process credential system. Without this, the user's process lacks the group ID in its supplementary group list, so access to a file with group permissions (660) is denied.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The user's primary group is not testgrp.
Why it's wrong here
A user's primary group does not determine whether group permissions on a file apply. The kernel checks not just the effective GID but the entire supplementary group list, which includes testgrp if the user was added as a secondary member. Whether testgrp is the login shell's initial group or an additional group is irrelevant; any matching group grants access. Therefore, this option does not explain the user's inability to access the file.
✓
The user did not log out and log back in.
Why this is correct
When a user is added to a group via usermod -aG or gpasswd, the change is written to /etc/group, but the running login session still holds the old supplementary group list cache. The kernel caches group memberships in the process credential structure at login, and does not reload them dynamically. Until the user logs out and back in (or runs newgrp/su), the new testgrp membership will not be reflected in group-based permission checks. This is exactly why the user cannot access the file.
✗
The file's group owner is not testgrp.
Why it's wrong here
The original scenario explicitly states that the file's group owner is testgrp. If the group owner were not testgrp, then the group permission bits would apply to a different group and the user's testgrp membership would indeed be irrelevant. However, since the file's group is given as testgrp, the group permission bits are directly associated with the user's group. This option contradicts the provided facts, so it cannot be the cause of the access failure.
✗
The file's ACL overrides group permissions.
Why it's wrong here
POSIX ACLs can supersede traditional group permission bits, because the ACL mask entry caps the effective permissions granted by the owning group. If the file had an ACL, the group bits displayed by ls -l might not reflect the actual access, and getfacl would show the ACL entries. The problem statement does not mention any ACL or show getfacl output, so there is no basis to blame ACLs. The failure is far better explained by the stale group membership that requires re-authentication.

Go deeper

EX200 Manage users and groups Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question