8:42 p.m.
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(a)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(a)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(a)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-cont...
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(a)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-pass...
> > > >
> > > >
https://github.com/containers/podman/blob/main/troubleshooting.md#33-cont...
> > > >
> > > > 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-sour...
> > > >
> > > > 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(a)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(a)lists.podman.io
> > > > >
> > > > > To unsubscribe send an email to podman-leave(a)lists.podman.io
> > > >
> > > > Podman mailing list -- podman(a)lists.podman.io
> > > >
> > > > To unsubscribe send an email to podman-leave(a)lists.podman.io