EX200 Manage containers Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Run the container with --privileged.

  Why it's wrong here

  Running the container with --privileged disables many security restrictions and grants all capabilities, but it does not change the ownership or mode of a bind-mounted host directory. The container's process running as UID 1001 is still subject to the same discretionary access control checks, and a root-owned directory with mode 0755 remains unwritable for that UID. Privileged mode is also a severe security risk, so it is both ineffective and unsafe for this scenario.

• ✗

  Add the user 1001 on the host to the root group.

  Why it's wrong here

  Adding the host user 1001 to the root group (GID 0) does not help because the bind-mounted directory is typically mode 0755 root:root, so group members have only read+execute permission, not write. Even if group write were granted, the container process is running with UID/GID 1001:1001, and Linux permission checks use the effective GID or supplementary groups; a host group membership in /etc/group is not automatically passed into the container's user namespace. The directory's group GID 0 and the container user's GID 1001 will not match, so write access remains denied.

• ✓

  Use 'podman unshare chown 1001:1001 /host/dir' to change host directory ownership.

  Why this is correct

  The command podman unshare chown 1001:1001 /host/dir changes ownership of the host directory from inside the same user namespace that the rootless container will use. Because podman unshare maps the container's UID/GID to the correct underlying host UIDs, the directory becomes owned by UID 1001 and GID 1001 as seen by the container, and the container user 1001 can write to it. This is the recommended approach for fixing rootless bind-mount permission issues, as it avoids requiring host-level root and precisely matches the container's identity.

• ✗

  Set setuid bit on the host directory.

  Why it's wrong here

  Setting the setuid bit (chmod u+s) on a directory is a red herring: it does not grant write access to the directory for other users, and Linux ignores the setuid bit on directories for this purpose (it has no standard effect on directory access). The setgid bit, not setuid, can affect the group ownership of newly created subdirectories/files, but it does not change discretionary access control checks for the directory itself when accessed over a bind mount. In this case, UID 1001 would still face the same read-only mode and lack write access.

Go deeper

Related to this question