rhatdan
commented
3 years ago Could this be apparmor blocking it?
Closed matpen closed 3 years ago
rhatdan
commented
3 years ago Could this be apparmor blocking it?
matpen
commented
3 years ago @rhatdan Thank you for the suggestion. I tend to exclude this hypothesis based on the following tests:
/var/log/kern.log nor in the kernel ring buffer via dmesg;matteo@ubuntu-vbox:~$ sudo systemctl stop apparmor
matteo@ubuntu-vbox:~$ sudo systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
matteo@ubuntu-vbox:~$ sudo reboot
matteo@ubuntu-vbox:~$ sudo service apparmor status
● apparmor.service - AppArmor initialization
Loaded: loaded (/lib/systemd/system/apparmor.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:apparmor(7)
http://wiki.apparmor.net/
matteo@ubuntu-vbox:~$ sudo aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
matteo@matteo-vbox:~$ sudo podman run \
--rm \
--privileged \
--runtime crun \
--pod test_pod \
--uidmap 0:1000:1000 \
--uidmap 1000:100000:1 \
"docker.io/library/ubuntu:18.04" whoami
Error: mount 'mqueue' to '/dev/mqueue': Operation not permitted: OCI permission deniedDoes this work if you don't deal with usernamespace?
rhatdan
commented
3 years ago sudo podman run \
--rm \
--privileged \
--runtime crun \
--pod test_pod \
"docker.io/library/ubuntu:18.04" whoamiOk looking a little deeper, I think the issue is doing this within a pod and using the user namespace. Sorry I was not paying attention to your command. Basically what is happening, is /dev/mqueue is being shared between the infra container of the pod and the container you are starting. Since the container you are starting is in a different user namespace, the /dev/mqueue in the pod, is not allowed to mount. I would guess that it is owned by real root.
To make this work, I believe we have to fix podman pod create to allow you to create a pod within a user namespace.
rhatdan
commented
3 years ago @giuseppe Agree?
matpen
commented
3 years ago Does this work if you don't deal with usernamespace?
Yes, that command works as expected.
Basically what is happening, is /dev/mqueue is being shared between the infra container of the pod and the container you are starting. Since the container you are starting is in a different user namespace, the /dev/mqueue in the pod, is not allowed to mount. I would guess that it is owned by real root.
This sounds plausible based on my research in the Internet and (limited) understanding of containers.
matteo@matteo-laptop:~$ sudo ls -ld /dev/mqueue
drwxrwxrwt 2 root root 40 Jan 15 08:28 /dev/mqueueTo make this work, I believe we have to fix podman pod create to allow you to create a pod within a user namespace.
Does this help at all?
giuseppe
commented
3 years ago Error: mount 'mqueue' to '/dev/mqueue': Operation not permitted: OCI runtime permission denied error
this error doesn't look like coming from crun.
Could you try moving --runtime crun (or setting crun as the default) before the run command? --runtime is a global flag to Podman, not for the run command:
$ sudo podman --runtime crun pod create --name test_pod
$ sudo podman --runtime crun run --rm --privileged --pod test_pod --uidmap 0:1000:1000 --uidmap 1000:100000:1 "docker.io/library/ubuntu:18.04" whoamiCould you try moving --runtime crun (or setting crun as the default) before the run command?
Just tried that... unfortunately I get the same error message.
giuseppe
commented
3 years ago could you check why it fails to use crun?
The error message Error: mount 'mqueue' to '/dev/mqueue': Operation not permitted: OCI permission denied is coming from runc, not crun
matpen
commented
3 years ago Ok so this is weird:
I get a different error message if I omit the --runtime crun (or maybe the same error, just formatted in a different way):
matteo@matteo-laptop:~$ sudo podman pod create --name test_pod2
fd137ec997b3cf901417cbf51f1979661fa5e396ab890705c9e1cc3d9d479265
matteo@matteo-laptop:~$ sudo podman run --rm --privileged --pod test_pod2 --uidmap 0:1000:1000 --uidmap 1000:100000:1 "docker.io/library/ubuntu:18.04" whoami
Error: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"sysfs\\\" to rootfs \\\"/var/lib/containers/storage/overlay/b25a11d2a576f9625b039ce170b914e656668c16746f80a50dff5c54fa8b2574/merged\\\" at \\\"/sys\\\" caused \\\"operation not permitted\\\"\"": OCI runtime permission denied errorWhen run with --log-level debug it looks like it is considering both runtimes, and finally using runc:
...
DEBU[0000] using runtime "/usr/sbin/runc"
DEBU[0000] using runtime "/usr/local/bin/crun"
...
DEBU[0000] running conmon: /usr/bin/conmon args=... -r /usr/sbin/runc -b /var/lib/containers/storage/...what is the --debug output when you use --runtime crun?
You can override the runtime settings in containers.conf, not in storage.conf
matpen
commented
3 years ago what is the --debug output when you use --runtime crun?
Similar to the above, but in this case it looks like it ends up using crun:
...
DEBU[0000] using runtime "/usr/sbin/runc"
DEBU[0000] using runtime "/usr/local/bin/crun"
...
DEBU[0000] running conmon: /usr/bin/conmon args=... -r /usr/local/bin/crun -b /var/lib/containers/storage/...You can override the runtime settings in containers.conf, not in storage.conf
True that, but I checked all paths listed in the documentation, and they dont exist on my system, e.g.:
matteo@matteo-laptop:~$ sudo cat /usr/share/containers/containers.conf
cat: /usr/share/containers/containers.conf: No such file or directory
matteo@matteo-laptop:~$ sudo cat /etc/containers/containers.conf
cat: /etc/containers/containers.conf: No such file or directory
matteo@matteo-laptop:~$ sudo cat /root/.config/containers/containers.conf
cat: /root/.config/containers/containers.conf: No such file or directory
matteo@matteo-laptop:~$ sudo cat /home/matteo/.config/containers/containers.conf
cat: /home/matteo/.config/containers/containers.conf: No such file or directoryIf you podman package comes without containers.conf, then you have not install containers-common package.
rhatdan
commented
3 years ago Running the commands on Fedora 33 I am getting a similar error.
sh-5.0# sudo podman pod create \
> --runtime crun \
> --name test_pod
0d05b29a362d17035c0f6d0581c4f0539fa831aded0a43ab64ef5bce6c424d1a
sh-5.0# sudo podman run \
> --rm \
> --privileged \
> --runtime crun \
> --pod test_pod \
> --uidmap 0:1000:1000 \
> --uidmap 1000:100000:1 \
> "docker.io/library/ubuntu:18.04" whoami
Error: error stat'ing file `/var/lib/containers/storage/overlay-containers/6afd0f476274af3c7b5f41aa080179f0e6169328bd4276a69ae5c941fe976ab1/userdata/shm`: Permission denied: OCI permission deniedThe issue is the pod's infra container is running in the host user namespace, the container is running in a different user namespace, When the container starts some of the cross mounts between the containers are getting permission deneid. We have to fix pod creation to be able to use a user namespace, so the infra container will run in the same user namespace as the containers running in the pod.
matpen
commented
3 years ago If you podman package comes without containers.conf, then you have not install containers-common package.
Seems like containers-common is installed, but does not contain a containers.conf
chengscott
commented
3 years ago Related PR #8393
giuseppe
commented
3 years ago The issue is the pod's infra container is running in the host user namespace, the container is running in a different user namespace, When the container starts some of the cross mounts between the containers are getting permission deneid. We have to fix pod creation to be able to use a user namespace, so the infra container will run in the same user namespace as the containers running in the pod.
crun supports this case and will use the correct namespaces inside of the container.
The issue I see here is that the owner of /var/lib/containers/storage/overlay-containers/6afd0f476274af3c7b5f41aa080179f0e6169328bd4276a69ae5c941fe976ab1/userdata/shm is not mapped in the new user namespace, you'd need to try with something like: --uidmap 0:0:1000:
# podman --runtime crun pod create --name test_pod
# podman --runtime crun run --rm --pod test_pod --uidmap 0:0:1000 fedora whoami
rootTried a few variations of the command with no luck:
matteo@matteo-laptop:~$ sudo podman --runtime crun pod create test_pod
matteo@matteo-laptop:~$ sudo podman --runtime crun run --rm --privileged --pod test_pod --uidmap 0:0:1000 "docker.io/library/fedora:latest" whoami
Error: mount `mqueue` to '/dev/mqueue': Operation not permitted: OCI runtime permission denied error
matteo@matteo-laptop:~$ sudo podman --runtime crun run --rm --privileged --pod test_pod --uidmap 0:0:1000 "docker.io/library/ubuntu:18.04" whoami
Error: mount `mqueue` to '/dev/mqueue': Operation not permitted: OCI runtime permission denied error
matteo@matteo-laptop:~$ sudo podman --runtime crun run --rm --privileged --pod test_pod --uidmap 0:0:1000 --uidmap 0:1000:1000 "docker.io/library/ubuntu:18.04" whoami
Error: setresuid(0): Invalid argument
writing file `/proc/9332/gid_map`: Invalid argument: OCI runtime error
matteo@matteo-laptop:~$ sudo podman --runtime crun run --rm --privileged --pod test_pod --uidmap 0:0:1000 --uidmap 0:1000:1000 --uidmap 1000:100000:1 "docker.io/library/ubuntu:18.04" whoami
Error: setresuid(0): Invalid argument
writing file `/proc/9332/gid_map`: Invalid argument: OCI runtime errorThe owner of /var/lib/containers/storage/overlay-containers/.../userdata (and all parent folders) is root, but I dont see the shm folder inside of it.
matteo@matteo-laptop:~$ sudo ls -la /var/lib/containers/storage/overlay-containers/7421c667446e421d4c49c4f3e7e93ab441abb4b2b43b2c25662c8640e970ab3d/userdata
total 20
drwx------ 3 root root 4096 Feb 27 16:50 .
drwx------ 3 root root 4096 Feb 27 16:49 ..
drwxr-xr-x 2 root root 4096 Feb 27 16:49 artifacts
srwx------ 1 root root 0 Feb 27 16:50 attach
-rw-r--r-- 1 root root 7950 Feb 27 16:50 config.json
prw-r--r-- 1 root root 0 Feb 27 16:50 ctl
-rw------- 1 root root 0 Feb 27 16:50 ctr.log
prw-r--r-- 1 root root 0 Feb 27 16:50 winsz
github-actions[bot]
commented
3 years ago A friendly reminder that this issue had no activity for 30 days.
rhatdan
commented
3 years ago @matpen Any update on this issue?
matpen
commented
3 years ago No update from my side: it keeps not working, as per my last message. I am able to reproduce on multiple system, but not to figure out what might be wrong.
rhatdan
commented
3 years ago Well it seems @giuseppe believes it works. with crun.
giuseppe
commented
3 years ago --uidmap 0:0:1000 --uidmap 0:1000:1000 --uidmap 1000:100000:1 is not a valid configuration as the range 0:1000 is assigned multiple times.
I've tried:
$ sudo podman --runtime crun pod create --name test_pod
381785df3f388b89ebfefc2dc582f7a1c546cc9e74fddab74d095ae06ae6296b
$ sudo podman --runtime crun run --rm --pod test_pod --uidmap 0:0:10000 alpine whoami
rootWith --privileged I see a different error:
$ sudo podman --runtime crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 alpine whoami
Error: OCI runtime error: create device `/dev/tty`: No such device or address--uidmap 0:0:1000 --uidmap 0:1000:1000 --uidmap 1000:100000:1 is not a valid configuration
True, I just tried a lot of combinations, including some wrong ones.
I've tried:
I do recognize that this works on your setup. I just tried yet another system, where I freshly installed crun for the test: same error.
At this stage, it appears obvious that it works for you and it does not work for me. Something must be different either in the fact that the host OS is different (in my tests, it is always Ubuntu), or in the way I install podman or crun.
I just hoped to get some pointers towards figuring out what the cause could be and help someone else who might find himself in the same situation. However, since we cannot reproduce it, it might just not be worth the effort: I will simply try a different approach for my use case.
giuseppe
commented
3 years ago At this stage, it appears obvious that it works for you and it does not work for me. Something must be different either in the fact that the host OS is different (in my tests, it is always Ubuntu), or in the way I install podman or crun.
crun alone is not enough, it also requires some newer features in the kernel, that should be available in Linux 5.3. I could be wrong about that, is there any newer kernel you can try?
giuseppe
commented
3 years ago another potential issue is that crun could be compiled without the support for the new mount API.
There is a check at build time, from the crun configure.ac file:
AC_MSG_CHECKING([for new mount API (fsconfig)])
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE([[
#include <linux/mount.h>
int cmd = FSCONFIG_CMD_CREATE;
]])],
[AC_MSG_RESULT(yes)
AC_DEFINE([HAVE_FSCONFIG_CMD_CREATE], 1, [Define if FSCONFIG_CMD_CREATE is available])],
[AC_MSG_RESULT(no)])Could you try building crun and see whether you get the following:
$ ./configure
$ grep HAVE_FSCONFIG_CMD_CREATE config.h
#define HAVE_FSCONFIG_CMD_CREATE 1or you could check more easily with:
$ grep FSCONFIG_CMD_CREATE /usr/include/linux/mount.h
FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */Thanks @giuseppe for not giving up on this.
crun alone is not enough, it also requires some newer features in the kernel, that should be available in Linux 5.3. I could be wrong about that, is there any newer kernel you can try?
As stated in the OP, the issue was first detected on 5.4.0-60-generic. Over time I upgraded the kernel a few times, and right now I am testing with a range of systems from 5.4.0-58-generic to 5.4.0-70-generic .
I do not feel confident to upgrade beyond what is officially provided by the OS vendor, but if you think that it can be useful, I will try a VM with a newer one. IIUC 5.10 should be latest stable at the time of this writing.
Could you try building crun and see whether you get the following:
Interesting. Both with kernel 5.4.0-65-generic and 5.4.0-70-generic I get
matteo@test1:/tmp/crun$ uname -a
Linux test1 5.4.0-65-generic #73~18.04.1-Ubuntu SMP Tue Jan 19 09:02:24 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
matteo@test1:/tmp/crun$ grep HAVE_FSCONFIG_CMD_CREATE config.h
/* #undef HAVE_FSCONFIG_CMD_CREATE */or you could check more easily with:
Even more interesting. On my system, that file does not exist, but I run a search with locate and found the following:
matteo@matteo-laptop:~$ grep FSCONFIG_CMD_CREATE \
/usr/include/sys/mount.h \
/usr/include/x86_64-linux-gnu/sys/mount.h \
/usr/src/linux-headers-5.3.0-62/include/linux/mount.h \
/usr/src/linux-hwe-5.4-headers-5.4.0-58/include/linux/mount.h \
/usr/src/linux-hwe-5.4-headers-5.4.0-58/include/uapi/linux/mount.h \
/usr/src/linux-hwe-5.4-headers-5.4.0-70/include/linux/mount.h \
/usr/src/linux-hwe-5.4-headers-5.4.0-70/include/uapi/linux/mount.h
/usr/src/linux-hwe-5.4-headers-5.4.0-58/include/uapi/linux/mount.h: FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */
/usr/src/linux-hwe-5.4-headers-5.4.0-70/include/uapi/linux/mount.h: FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */Note how we get results only for the UAPI files (not sure about what this implies).
I am not familiar with the above results, but they do seem to hint towards a missing kernel feature.
giuseppe
commented
3 years ago The kernel is fine but the /usr/include/sys/mount.h header file is outdated and misses the definition for FSCONFIG_CMD_CREATE. So crun is built without the support for such features.
We could probably fix the issue in crun itself and define the missing symbols when they are missing.
giuseppe
commented
3 years ago could you try to build crun with the following patch?
diff --git a/src/libcrun/linux.c b/src/libcrun/linux.c
index 9e2264f..95bd9e7 100644
--- a/src/libcrun/linux.c
+++ b/src/libcrun/linux.c
@@ -76,6 +76,10 @@
# define MOVE_MOUNT_T_EMPTY_PATH 0x00000040
#endif
+#ifndef HAVE_FSCONFIG_CMD_CREATE
+# define FSCONFIG_CMD_CREATE 6
+#endif
+
struct remount_s
{
struct remount_s *next;
@@ -543,7 +547,6 @@ open_mount_target (libcrun_container_t *container, const char *target_rel, libcr
static int
fsopen_mount (runtime_spec_schema_defs_mount *mount)
{
-#ifdef HAVE_FSCONFIG_CMD_CREATE
cleanup_close int fsfd = -1;
int ret;
@@ -556,32 +559,15 @@ fsopen_mount (runtime_spec_schema_defs_mount *mount)
return ret;
return syscall_fsmount (fsfd, FSMOUNT_CLOEXEC, 0);
-#else
- (void) mount;
- (void) syscall_fsopen;
- (void) syscall_fsconfig;
- (void) syscall_fsmount;
- errno = ENOSYS;
- return -1;
-#endif
}
static int
fs_move_mount_to (int fd, int dirfd, const char *name)
{
-#ifdef HAVE_FSCONFIG_CMD_CREATE
if (name)
return syscall_move_mount (fd, "", dirfd, name, MOVE_MOUNT_F_EMPTY_PATH);
return syscall_move_mount (fd, "", dirfd, "", MOVE_MOUNT_T_EMPTY_PATH | MOVE_MOUNT_F_EMPTY_PATH);
-#else
- (void) fd;
- (void) dirfd;
- (void) name;
- (void) syscall_move_mount;
- errno = ENOSYS;
- return -1;
-#endif
}
enum
The patch applies correctly against master
matteo@test1:/tmp/crun$ patch -p1 < /tmp/crun.patch
patching file src/libcrun/linux.c
Hunk #3 succeeded at 559 with fuzz 1.but build fails with
matteo@test1:/tmp/crun$ ./autogen.sh
...
matteo@test1:/tmp/crun$ ./configure
...
matteo@test1:/tmp/crun$ make
...
src/libcrun/linux.c: In function 'fsopen_mount':
src/libcrun/linux.c:553:39: error: 'FSOPEN_CLOEXEC' undeclared (first use in this function); did you mean 'SOCK_CLOEXEC'?
fsfd = syscall_fsopen (mount->type, FSOPEN_CLOEXEC);
^~~~~~~~~~~~~~
SOCK_CLOEXEC
src/libcrun/linux.c:553:39: note: each undeclared identifier is reported only once for each function it appears in
src/libcrun/linux.c:561:33: error: 'FSMOUNT_CLOEXEC' undeclared (first use in this function); did you mean 'FSOPEN_CLOEXEC'?
return syscall_fsmount (fsfd, FSMOUNT_CLOEXEC, 0);
^~~~~~~~~~~~~~~
FSOPEN_CLOEXECFull log attached, it case it is useful.
giuseppe
commented
3 years ago thanks, some other missing symbols. Could you add:
#define FSOPEN_CLOEXEC 0x00000001
#define FSMOUNT_CLOEXEC 0x00000001at the beginning of the linux.c file and try again?
matpen
commented
3 years ago With that, crun was built successfully. Here is the updated patch.
Unfortunately though, it does not seem to solve the problem:
matteo@test1:/tmp/crun$ crun --version
crun version 0.18.90-a72dd-dirty
commit: a72dd4d303f48e23f3a74a103216363167e4407f
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
matteo@test1:/tmp/crun$ sudo podman --runtime crun pod create --name test_pod
7cc7e5b939ab7fa5e3b75b5929ef0b3bfcba063823115bc88f4000ffbd10196e
matteo@test1:/tmp/crun$ sudo podman --runtime crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
Error: mount `mqueue` to `/dev/mqueue`: Operation not permitted: OCI runtime permission denied errorThe kernel is fine but the /usr/include/sys/mount.h header file is outdated
Can you share thoughts about how this came to be? Anything I can try on my side?
giuseppe
commented
3 years ago where have you copied the crun binary?
Could you specify the full path to podman:
sudo podman --runtime /path/to/the/just/built/crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoamiCan you share thoughts about how this came to be? Anything I can try on my side?
because it lacks definitions for symbols that are present in the current kernel, as you showed with the grep command above
matpen
commented
3 years ago where have you copied the crun binary?
I accepted the system default with a simple make install
matteo@test1:/tmp/crun$ which crun
/usr/local/bin/crunCould you specify the full path to podman:
No luck
matteo@test1:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun pod create --name test_pod
a99dc2fdf3a7870ee219b80f7cb9d39c21d6499363a860a8669725ea8057da63
matteo@test1:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
Error: mount `mqueue` to `/dev/mqueue`: Operation not permitted: OCI runtime permission denied errorbecause it lacks definitions for symbols that are present in the current kernel, as you showed with the grep command above
Thank you, I understand this. My question was more "how can be that file be outdated, if the kernel is fine (seems recent enough to me)." and "Is there a (relatively) simple fix for that (eg. update the kernel headers)?"
giuseppe
commented
3 years ago so I had a look under Ubuntu 18.04 and there are some other missing definitions:
#define __NR_move_mount 429
#define __NR_fsopen 430
#define __NR_fsconfig 431
#define __NR_fsmount 432It works when I add also these ones on top of the previous patches.
For a test, if you add these definitions to the same linux.c file, does it work for you?
These definitions are arch specific so unfortunately I don't think we can add the workaround in crun.
matpen
commented
3 years ago Still not working, but at least now we get a different error:
matteo@test1:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
Error: create device `/dev/tty`: No such device or address: OCI runtime error
matteo@test1:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
Error: sethostname: Operation not permitted: OCI runtime permission denied errorNote that the first error is the same you mentioned here, so I removed --privileged as you suggested. The second error is instead new to me.
giuseppe
commented
3 years ago indeeed, this is a new one now. Can you try adding --uts=private to the podman run command?
matpen
commented
3 years ago uhmm... I get the following. Too old podman perhaps?
matteo@test1:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --uidmap 0:0:10000 --uts=private "docker.io/library/ubuntu:18.04" whoami
Error: --uts "private" is not valid
matteo@test1:/tmp/crun$ podman --version
podman version 1.6.2That is ancient, I thought you were on 2.2.1
matpen
commented
3 years ago No problem: I switched to a VM where I had tested 2.2.1, upgraded to 3.0.1, and followed the steps discussed today. And with success!
matteo@ubuntu-vbox:/tmp/crun$ uname -a
Linux ubuntu-vbox 5.4.0-70-generic #78~18.04.1-Ubuntu SMP Sat Mar 20 14:10:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
matteo@ubuntu-vbox:/tmp/crun$ podman --version
podman version 3.0.1
matteo@ubuntu-vbox:/tmp/crun$ crun --version
crun version 0.18.90-a72dd-dirty
commit: a72dd4d303f48e23f3a74a103216363167e4407f
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
matteo@ubuntu-vbox:/tmp/crun$ sudo podman pod create --name test_pod
f54d71be5c18ad74a313922e6ae0614c1738d06267990bc929e21491796cfc76
matteo@ubuntu-vbox:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --privileged --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
Error: OCI runtime error: create device `/dev/tty`: No such device or address
matteo@ubuntu-vbox:/tmp/crun$ sudo podman --runtime /usr/local/bin/crun run --rm --pod test_pod --uidmap 0:0:10000 "docker.io/library/ubuntu:18.04" whoami
rootSo finally here is the working patch. Did you mention that it cannot be released with crun? Do you suggest applying it to my systems, or can you envision some more maintainable solution?
giuseppe
commented
3 years ago And with success!
Thanks for confirming!
or can you envision some more maintainable solution?
I think the correct fix is to get the updated header files on Ubuntu 18.04, so that crun can be compiled with the support for the new mount API.
matpen
commented
3 years ago How does one "get the updated header files"? It looks like they already are updated on my system. Is this something that the OS vendor should do?
matteo@ubuntu-vbox:~$ dpkg -s linux-headers-generic-hwe-18.04
Package: linux-headers-generic-hwe-18.04
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 13
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
Architecture: amd64
Source: linux-meta-hwe-5.4
Version: 5.4.0.70.78~18.04.63
Depends: linux-headers-5.4.0-70-generic
Description: Generic Linux kernel headers
This package will always depend on the latest generic kernel headers
available.Is this something that the OS vendor should do?
yes that is not in our control.
You will need an updated /usr/include/linux/mount.h as well as having the definitions for the different syscalls I've listed above.
Could you try on a newer Ubuntu release?
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I am filing this issue to re-open the discussion on https://github.com/containers/podman/issues/6843. I just tested with the latest versions of the involved software, and it does not seem to work.
Note that: