In nginx
podman container nginx
user is used to run nginx
server.
On the host machine ls -alh
:
drwxrwx--- 2 myuser myuser 4.0K Aug 10 22:23 .
drwxrwx--- 3 myuser myuser 4.0K Aug 10 22:59 ..
-rw-rw---- 1 myuser myuser 46 Aug 10 22:24 .htpasswd
The same folder inside container ls -alh
:
drwxrwx--- 2 root root 4.0K Aug 10 22:23 .
drwxr-xr-x 1 root root 4.0K Aug 10 11:05 ..
-rw-rw---- 1 root root 46 Aug 10 22:24 .htpasswd
nginx
user inside container can't access .htpasswd
because of o-rwx
.
Question: what is the commonly used pattern to handle this kind of cases in rootless container universally? Maybe it is possible to create group (used later as file-group owner) which gathers all ranges from subuid
/subgid
for particular host user - but how to achieve this?
By using the command-line option
--uidmap
you can specify how the myuser UID and the myuser sub UIDs are mapped into the container. (See the man page forpodman run
).The command-line option
--gidmap
works in the same way but for GIDs instead of UIDs.Let's look up the UID and GID for the user nginx in the container image docker.io/library/nginx
Result:
The numbers are later used when setting two shell variables
(The shell variables container_uid and container_gid don't have any meaning outside this post. They are just introduced to make the answer easier to read)
Take a look in the files /etc/subuid and /etc/subgid on the host
The user myuser has these sub UIDs and sub GIDs.
Result:
myuser has 65536 sub UIDs and 65536 sub GIDs.
The numbers are later used when setting two shell variables
(The shell variables subuid_size and subgid_size don't have any meaning outside this post. They are just introduced to make the answer easier to read)
Instead of looking up subuid_size and subgid_size in /etc/subuid and /etc/subgid, a more general method is to run the commands
The advantage is that this also works when the file /etc/nsswitch.conf is used instead of /etc/subuid and /etc/subgid. (See
man subuid
)Demo 1: map the user myuser on the host to the user root inside the container
There is no need to specify
--uidmap
nor--gidmap
because this is the standard mapping.Create the world writable directory demo1
Create a new file, running as root inside the container:
Create a new file, running as nginx inside the container:
List the files on the host
Result: The file created_by_root is owned by myuser:myuser
Demo 2: map the user myuser on the host to the user nginx inside the container
Create the world writable directory demo2
Create a new file, running as root inside the container:
Create a new file, running as nginx inside the container.
List the files on the host
Result: The file created_by_nginx is owned by myuser:myuser
Conclusion
Use
--uidmap
and--gidmap
in the same way as in Demo 2.Troubleshooting tip
I wrote a troubleshooting tip: Passed-in devices or files can't be accessed in rootless container (UID/GID mapping problem) that contains the method described in Demo 2
You should figure out what is the initial host UID for the container's nginx UID (just touch a file from the container using the user under which
nginx
is running, or check its log files, or check the running nginx process. Then usestat
orls -ln
from the initial host user): some big UID value, let's suppose it's 100030.Then from the initial host's unprivileged user you can use
setfactl
to grant additional access to user 100030. This should be something like:If you want the nginx user to be able to write (which might not be a good idea), you can replace
rX
withrwX
or do it only in select directories. The duplication starting withd:
stands for default ACLs, so newly created directories and files also inherit the same additional ACLs. When ACLs are set, output ofls
displays a+
and the ACL mask instead of the group, so it might look surprising.Here are various references about ACLs:
acl(5)