User namespace remapping in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of user namespace remapping in Docker?

User namespace remapping changes how user IDs inside a container map to user IDs on the host. What is the main reason Docker uses this feature?

A To isolate container users from host users for better security

B To improve container startup speed by caching user IDs

C To allow containers to share the same user IDs as the host

D To enable containers to run without any user permissions

💡 Hint

Think about how containers can be safer by separating their users from the host system users.

User namespace remapping isolates container user IDs from host user IDs, reducing the risk that a container user can affect the host system. This improves security by preventing privilege escalation.

💻 Command Output

intermediate

What is the output of 'docker info' regarding user namespace remapping when it is enabled?

After enabling user namespace remapping in Docker, you run docker info. What line indicates that user namespace remapping is active?

Docker

docker info

A Userns Mode: private

B Userns Mode: remapped

C Userns Mode: enabled

D Userns Mode: host

💡 Hint

Look for the exact phrase Docker uses to show remapping is active.

When user namespace remapping is enabled, docker info shows Userns Mode: remapped. This confirms the feature is active.

❓ Configuration

advanced

Which configuration snippet correctly enables user namespace remapping in Docker daemon.json?

You want to enable user namespace remapping by editing /etc/docker/daemon.json. Which snippet is correct?

A

{
  "userns-remap": "default"
}

B

{
  "userns_remap": "default"
}

C

{
  "userns-remap": true
}

D

{
  "user_namespace_remap": "default"
}

💡 Hint

Check the exact key name Docker expects in the JSON config.

The correct key is "userns-remap" with a hyphen, and the value is usually "default" to enable remapping with default settings.

❓ Troubleshoot

advanced

Why does Docker fail to start after enabling user namespace remapping with an invalid subuid range?

You enabled user namespace remapping but Docker daemon fails to start. You suspect the /etc/subuid and /etc/subgid files are misconfigured. What is the most likely cause?

A The subuid and subgid ranges overlap with existing host user IDs

B The Docker version does not support user namespace remapping

C The Docker daemon.json file has a syntax error unrelated to userns

D The subuid and subgid files are missing or empty for the remap user

💡 Hint

Check if the remap user has assigned subordinate IDs in the system files.

User namespace remapping requires the remap user to have valid subordinate UID and GID ranges in /etc/subuid and /etc/subgid. Missing or empty entries cause Docker to fail starting.

🔀 Workflow

expert

What is the correct sequence to enable user namespace remapping and verify it works?

Arrange the steps in the correct order to enable user namespace remapping on a Docker host and confirm it is active.

A 3,2,1,4

B 1,3,2,4

C 3,1,2,4

D 1,2,3,4

💡 Hint

Think about verifying prerequisites before changing config, then restarting, then checking status.

First verify the subordinate UID/GID mappings exist (3). Then edit daemon.json (1). Restart Docker (2). Finally, confirm with docker info (4).

Practice

1.

What is the main purpose of user namespace remapping in Docker?

easy

A. To allow containers to use more CPU cores

B. To increase container startup speed

C. To enable automatic container backups

D. To improve security by isolating container user IDs from host user IDs

Solution

1. Step 1: Understand user namespace remapping concept

   User namespace remapping changes container user IDs so they do not match host user IDs.

2. Step 2: Identify the security benefit

   This isolation reduces risk if a container is compromised, protecting the host system.

3. Final Answer:

   To improve security by isolating container user IDs from host user IDs -> Option D

4. Quick Check:

   User namespace remapping = security isolation [OK]

Hint: User namespace remapping isolates users for security [OK]

Common Mistakes:

• Thinking it improves performance
• Confusing with resource limits
• Assuming it enables backups

2.

Which of the following is the correct way to enable user namespace remapping in Docker's daemon.json file?

{
  "userns-remap": "default"
}

easy

A. { "userns-remap": true }

B. { "userns-remap": "enabled" }

C. { "userns-remap": "default" }

D. { "userns-remap": 1 }

Solution

1. Step 1: Check Docker daemon configuration syntax

   The correct key is "userns-remap" and it expects a string value like "default" or a username.

2. Step 2: Validate options

   Only { "userns-remap": "default" } uses the correct key and a valid string value "default".

3. Final Answer:

   { "userns-remap": "default" } -> Option C

4. Quick Check:

   Correct key and string value = { "userns-remap": "default" } [OK]

Hint: Use string "default" for userns-remap in daemon.json [OK]

Common Mistakes:

• Using boolean true instead of string
• Using numeric values
• Using invalid strings like "enabled"

3.

Given Docker daemon configured with "userns-remap": "default", what will be the output of id -u inside a container run as root?

medium

A. 100000

B. 0

C. 65534

D. 1

Solution

1. Step 1: Understand user ID remapping

   When user namespace remapping is enabled, the container runs in its own user namespace where root is UID 0 inside the container.

2. Step 2: Identify the output of id -u inside container

   Inside the container, id -u for the root user reports 0, as it views UIDs from the container's namespace perspective. The host sees the remapped UID (e.g., 100000).

3. Final Answer:

   0 -> Option B

4. Quick Check:

   id -u inside container shows 0 for root [OK]

Hint: Inside container, root UID is 0 despite host remapping [OK]

Common Mistakes:

• Confusing container-internal UID (0) with host-remapped UID (100000)
• Thinking remapping changes UID view inside container
• Choosing 65534 which is nobody user

4.

You enabled user namespace remapping in Docker but containers fail to start with permission errors. What is the most likely cause?

medium

A. The remapped user IDs do not have permission on container files

B. Docker daemon.json syntax is incorrect

C. Containers are using too much CPU

D. Docker version does not support user namespaces

Solution

1. Step 1: Analyze permission errors after enabling userns-remap

   User namespace remapping changes container user IDs, so files owned by root on host may not be accessible by remapped IDs.

2. Step 2: Identify cause of permission failure

   If the remapped user IDs lack permissions on container files or volumes, containers fail to start with permission denied errors.

3. Final Answer:

   The remapped user IDs do not have permission on container files -> Option A

4. Quick Check:

   Permission errors = remapped UID lacks file access [OK]

Hint: Check file permissions for remapped user IDs [OK]

Common Mistakes:

• Blaming daemon.json syntax without checking logs
• Assuming CPU limits cause permission errors
• Ignoring Docker version compatibility

5.

You want to run a container with user namespace remapping but need the container's root user to have access to a host directory /data. What is the best way to configure this?

hard

A. Change ownership of /data on host to the remapped UID range

B. Disable user namespace remapping for this container

C. Run the container as a non-root user

D. Mount /data as read-only volume

Solution

1. Step 1: Understand user namespace remapping effect on file access

   With remapping, container root maps to a high UID on host, so host files must be owned or accessible by that UID.

2. Step 2: Adjust host directory ownership

   Changing /data ownership to the remapped UID range allows container root to access it safely without disabling remapping.

3. Final Answer:

   Change ownership of /data on host to the remapped UID range -> Option A

4. Quick Check:

   Host directory ownership matches remapped UID for access [OK]

Hint: Match host directory ownership to remapped UID [OK]

Common Mistakes:

• Disabling remapping loses security benefits
• Running as non-root may not solve access needs
• Mounting read-only prevents write access