4:48 p.m.
Hi All,
trying to do the following, but it won't work neither on fedora nor EL7
$ cat /etc/fedora-release
Fedora release 30 (Thirty)
$ podman version
Version: 1.6.2
RemoteAPI Version: 1
Go Version: go1.12.10
OS/Arch: linux/amd64
$ id -u
1000
$ id -g
1000
$ mkdir /tmp/foo/bar -p
$ chmod 0750 /tmp/foo /tmp/foo/bar
$ echo hello > /tmp/foo/bar/msg
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
hello
-> this works
$ sudo chown root /tmp/foo
$ ls -anl /tmp/foo
total 0
drwxr-x---. 3 0 1000 60 5. Nov 23:29 .
drwxrwxrwt. 30 0 0 2420 5. Nov 23:34 ..
drwxr-x---. 2 1000 1000 60 5. Nov 23:30 bar
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
Error: time="2019-11-05T23:35:13+01:00" level=warning msg="exit status
1"
time="2019-11-05T23:35:13+01:00" level=error
msg="container_linux.go:346: starting container process caused
\"process_linux.go:449: container init caused \\\"rootfs_linux.go:58:
mounting \\\\\\\"/tmp/foo/bar\\\\\\\" to rootfs
\\\\\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\\\\\"
at \\\\\\\"/data\\\\\\\" caused \\\\\\\"stat /tmp/foo/bar: permission
denied\\\\\\\"\\\"\""
container_linux.go:346: starting container process caused
"process_linux.go:449: container init caused \"rootfs_linux.go:58:
mounting \\\"/tmp/foo/bar\\\" to rootfs
\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\"
at \\\"/data\\\" caused \\\"stat /tmp/foo/bar: permission
denied\\\"\"":
OCI runtime permission denied error
-> this fails somehow, although my user has rights in that path.
$ sudo chmod 0755 /tmp/foo
$ ls -anl /tmp/foo
total 0
drwxr-xr-x. 3 0 1000 60 5. Nov 23:29 .
drwxrwxrwt. 30 0 0 2420 5. Nov 23:35 ..
drwxr-x---. 2 1000 1000 60 5. Nov 23:30 bar
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
hello
So whenever a directory in the path to the volume that should go into my
container is not browseable by my uid (although my group can!) I cannot
mount it as a volume.
debug logs won't give any further info.
Why do I want to do that?
I have userdirectories that are purely used as chroots for SFTP through
sshd. Thus they *must* be root owned, but group readable/listable, so
the root of the chroot can't be overwritten. See sshd_config for more
details.
Now I'd like to run containers as the particular user, operating on some
directories within that chroot path.
By default these chroot-directories are setup with 0750 and thus failing
in my case.
While 0755 might still be an option/workaround, I am wondering what the
reason for that requirement is?
It looks like a bug to me. Shall I open an issue, but where?
~mh
10:01 a.m.
the issue here is that you are mapping your own user to the same id
inside of the user namespace.
That means the root user inside of the user namespace will be mapped to
another ID, which is the first ID specified in /etc/sub?id for your
user. It is the same user that will configure the mount namespace,
including the bind mount that fails in your test.
The OCI runtime, after changing uid/gid to the specified ones (with
--userns=keep-id are the same $UID:$GID you have on the host), drops any
additional group that the user had when launching the container.
I've added a function to crun 0.10.4 to have the possibility to not drop
additional groups for such cases, it can be enabled from podman with
"--annotation io.crun.keep_original_groups=1", it might help you.
Giuseppe
mh <mh+podman(a)scrit.ch> writes:
Hi All,
trying to do the following, but it won't work neither on fedora nor EL7
$ cat /etc/fedora-release
Fedora release 30 (Thirty)
$ podman version
Version: 1.6.2
RemoteAPI Version: 1
Go Version: go1.12.10
OS/Arch: linux/amd64
$ id -u
1000
$ id -g
1000
$ mkdir /tmp/foo/bar -p
$ chmod 0750 /tmp/foo /tmp/foo/bar
$ echo hello > /tmp/foo/bar/msg
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
hello
-> this works
$ sudo chown root /tmp/foo
$ ls -anl /tmp/foo
total 0
drwxr-x---. 3 0 1000 60 5. Nov 23:29 .
drwxrwxrwt. 30 0 0 2420 5. Nov 23:34 ..
drwxr-x---. 2 1000 1000 60 5. Nov 23:30 bar
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
Error: time="2019-11-05T23:35:13+01:00" level=warning msg="exit status
1"
time="2019-11-05T23:35:13+01:00" level=error
msg="container_linux.go:346: starting container process caused
\"process_linux.go:449: container init caused \\\"rootfs_linux.go:58:
mounting \\\\\\\"/tmp/foo/bar\\\\\\\" to rootfs
\\\\\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\\\\\"
at \\\\\\\"/data\\\\\\\" caused \\\\\\\"stat /tmp/foo/bar: permission
denied\\\\\\\"\\\"\""
container_linux.go:346: starting container process caused
"process_linux.go:449: container init caused \"rootfs_linux.go:58:
mounting \\\"/tmp/foo/bar\\\" to rootfs
\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\"
at \\\"/data\\\" caused \\\"stat /tmp/foo/bar: permission
denied\\\"\"":
OCI runtime permission denied error
-> this fails somehow, although my user has rights in that path.
$ sudo chmod 0755 /tmp/foo
$ ls -anl /tmp/foo
total 0
drwxr-xr-x. 3 0 1000 60 5. Nov 23:29 .
drwxrwxrwt. 30 0 0 2420 5. Nov 23:35 ..
drwxr-x---. 2 1000 1000 60 5. Nov 23:30 bar
$ podman run -it --userns=keep-id -v \
/tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
hello
So whenever a directory in the path to the volume that should go into my
container is not browseable by my uid (although my group can!) I cannot
mount it as a volume.
debug logs won't give any further info.
Why do I want to do that?
I have userdirectories that are purely used as chroots for SFTP through
sshd. Thus they *must* be root owned, but group readable/listable, so
the root of the chroot can't be overwritten. See sshd_config for more
details.
Now I'd like to run containers as the particular user, operating on some
directories within that chroot path.
By default these chroot-directories are setup with 0750 and thus failing
in my case.
While 0755 might still be an option/workaround, I am wondering what the
reason for that requirement is?
It looks like a bug to me. Shall I open an issue, but where?
~mh
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
3:19 p.m.
On 06.11.19 17:01, Giuseppe Scrivano wrote:
the issue here is that you are mapping your own user to the same id
inside of the user namespace.
That means the root user inside of the user namespace will be mapped to
another ID, which is the first ID specified in /etc/sub?id for your
user. It is the same user that will configure the mount namespace,
including the bind mount that fails in your test.
Thank you! This explanation really helped and it confirms the theory I
had why it's not working. Assumed the mount is done as that "fake"-root
uid.
I was able to workaround it by doing:
setfacl -m user:FIRST_SUBUID:rx /tmp/foo
This made the container start :)
The OCI runtime, after changing uid/gid to the specified ones (with
--userns=keep-id are the same $UID:$GID you have on the host), drops any
additional group that the user had when launching the container.
I've added a function to crun 0.10.4 to have the possibility to not drop
additional groups for such cases, it can be enabled from podman with
"--annotation io.crun.keep_original_groups=1", it might help you.
Good to know, though crun won't make it to EL7 I guess, so the approach
above is probably the way to go for me in that situation.
~mh
1874
days inactive
1875
days old
2 comments
2 participants
participants (2)
-
Giuseppe Scrivano -
mh