Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?
I assume you meant "Why is the user 1000 inside the container mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?" The complicated part of using --uidmap together with rootless podman (i.e. running Podman from an unprivileged account), is that the mapping happens over two mappings steps. The first step is handled by Podman itself and can't be controlled by the user. The option --uidmap controls the second mapping step. So we have two steps: first mapping second mapping host UID --> intermediate UID --> container UID The name "intermediate UID" is just a name to be able to reason about the two mapping steps. The middle number in --uidmap is actually the intermediate UID when you are running rootless Podman. In other words --uidmap $uid:0:1 means: map the intermediate UID 0 to the container UID 1000. Why do we need to pass that option? The reason for this is that the first mapping step always maps the user's regular host UID to the intermediate UID 0. For instance if the user's regular UID on the host is 3456 and the container UID is $uid, the command-line argument --uidmap $uid:0:1 would map the host UID 3456 to the container UID $uid host UID (3456) -> intermediate UID (0) -> container UID ($uid) If you search for the text string "First mapping step" on the web page https://docs.podman.io/en/latest/markdown/podman-run.1.html#uidmap-container... you will find a table that describes how Podman handles the first mapping step.
Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)?
The digit 1 actually means intermediate UID 1. The first mapping step mapped the lowest subordinate UID to intermediate UID 1. Passing --uidmap 0:1:$uid translates to: host UID (first subordinate UID) -> intermediate UID (1) -> container UID 1 The last number in "--uidmap 0:1:$uid", $uid, specifies how many consecutive IDs should be mapped.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? No, it didn't work for me. Sorry, I think ":U" is not so useful for the container image docker.io/gogs/gogs
should I file a bug report? I think everything is working as expected so there is no need for that.
On Sat, Feb 19, 2022 at 3:42 AM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
I tried running the shell script you provided, and it does work.
Could you please explain to me what the `--uidmap`s are doing, please? Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)? Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)? The last one [--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid))] seems to be mapping all the rest of the users beyond 1000 to 1000+ on the host, for the entire subuid range. That one makes a bit of sense. (But even then, if I have another user `1001` on the host, that is mapping `1001` inside the container to that user?)
Clearly, there are a lot of gaping holes in my understanding of namespaces. I would really appreciate it if you would point me to the right direction.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? If it is not doing what it is supposed to do, should I file a bug report? Likewise with `--userns=keep-id`.
Thank you for your time and patience.
------- Original Message -------
On Saturday, February 19th, 2022 at 2:28 AM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
Prafulla, I did some more testing.
It looks to be working.
w3m was able to browse the web page:
[tester@laptop ~]$ w3m http://localhost:10880
An ssh client was able to connect to the ssh server.
[tester@laptop ~]$ ssh -p 10022 localhost
The authenticity of host '[localhost]:10022 ([::1]:10022)' can't be established.
ED25519 key fingerprint is SHA256:rRXoPCat1mA7cGWCr9TOUxGYzQafFUEr2yXKIH+Oe8w.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:10022' (ED25519) to the list
of known hosts.
tester@localhost: Permission denied (publickey,keyboard-interactive).
[tester@laptop ~]$
Maybe you could try the Bash script run.sh and see if it works for you?
Kind regards
Erik Sjölund
On Fri, Feb 18, 2022 at 8:49 PM Erik Sjölund erik.sjolund@gmail.com wrote:
I tried to run this Bash script
#!/bin/bash
uid=1000
gid=1000
subuidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
subgidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))
podman run --rm \
-v ./gogs:/data:Z \
--uidmap $uid:0:1 \
--uidmap 0:1:$uid \
--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \
--gidmap $gid:0:1 \
--gidmap 0:1:$gid \
--gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \
--name=gogs -p 10022:22 -p 10880:3000 \
docker.io/gogs/gogs
[tester@laptop ~]$ podman --version
podman version 3.4.4
[tester@laptop ~]$ bash run.sh
usermod: no changes
Feb 18 19:14:58 syslogd started: BusyBox v1.33.1
2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini"
not found. Ignore this warning if you're running for the first time
2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace)
2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev
2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs
2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs
2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini
2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log
2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC
2022/02/18 19:14:58 [TRACE] Build commit:
8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed
2022/02/18 19:14:58 [ INFO] Run mode: Development
Feb 18 19:14:58 sshd[45]: Server listening on :: port 22.
Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22.
2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000
I didn't try connecting with a web browser but at least the file
permissions look OK.
In another shell:
[tester@fcos ~]$ ls -l gogs
total 4
drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git
drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs
drwx------. 2 tester tester 4096 Feb 18 19:14 ssh
[tester@fcpos ~]$
I haven't figured out yet why adding --user $uid:$gid fails though.
Kind regards,
Erik Sjölund
On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri
prafulla.giri@protonmail.com wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with:
$ mkdir gogs
$ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund erik.sjolund@gmail.com wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io