Hallo, thanks for advice!

But sorry, for me it did not work:

  podman create --name ctest --pod test --ipc private --cap-add=SYS_PTRACE --init --replace test-image
  container=99425540b8e3544409e4086cf1a44b04cf9f402f1d7505f807324dce71eb2373
  podman init test
  test
  podman inspect -f '{{.State.Pid}}' test
  pid=2157674
  sudo nsenter --target 2157674 --user --ipc sysctl fs.mqueue.msg_max=64
  sysctl: permission denied on key "fs.mqueue.msg_max"

Anyway, even if it would work, this method would not be appropriate in my case,
since eventually my containers should be run from quadlet (which in turn uses
podman kube play). Shell is used only during development.

Best regards,
On 29.11.2023 18:10, Lewis Gaul wrote:
Hi,

I think this is the same thing I raised in https://github.com/containers/podman/discussions/19737?

This seems to be a kernel limitation - I'm not sure where the mqueue limits come from when creating a new IPC namespace, but it doesn't inherit the limits from the parent namespace and the root user within the user namespace does not have permissions to modify the limits. This was supposedly fixed in a recent kernel version although I haven't tested it.

The workaround I'm currently using (requiring sudo permissions) is along the lines of:
podman create --ipc private --name ctr_foo ...
podman init ctr_foo
ctr_pid=$(podman inspect -f '{{.State.Pid}}' ctr_foo)
sudo nsenter --target $ctr_pid --user --ipc sysctl fs.mqueue.msg_max=64
podman start ctr_foo

Obviously this isn't ideal, and I'd be open to alternatives...

Regards,
Lewis

On Mon, 27 Nov 2023 at 12:23, Daniel Walsh <dwalsh@redhat.com> wrote:
On 11/27/23 02:04, Михаил Иванов wrote:
Hallo,

For me rootful works:

island:container [master]> cat /proc/sys/fs/mqueue/msg_max
256

$ podman run alpine ls -ld /proc/sys/fs/mqueue/msg_max
-rw-r--r--    1 nobody   nobody           0 Nov 27 12:10 /proc/sys/fs/mqueue/msg_max

Since it is owned by real root, a rootless user can not write to it.  I guess we could ague this is a bug with the kernel. mqeueu/msg_max should be owned by root of the user namespace as opposed to real root.

## Rootful:
island:container [master]> sudo podman run --sysctl=fs.mqueue.msg_max=64 --rm centos cat /proc/sys/fs/mqueue/msg_max
64

## Rootless:
island:container [master]> podman run --sysctl=fs.mqueue.msg_max=64 --rm centos cat /proc/sys/fs/mqueue/msg_max
Error: crun: open `/proc/sys/fs/mqueue/msg_max`: Permission denied: OCI permission denied

## What rootless gets by default (changed as compared to host setting!):
island:container [master]> podman run --rm centos cat /proc/sys/fs/mqueue/msg_max
10

Rgrds,
On 25.11.2023 20:17, Daniel Walsh wrote:
On 11/25/23 10:44, Михаил Иванов wrote:
Hallo,
Is it possible to get podman to propagate current host fs.mqueue.msg_max
value to rootless container? I can do that if I specify --ipc host when
running the container, but this also exposes other ipc stuff from host
to container, including shared memory, which I do not want.

If I specify --sysctl fs.mqueue.msg_size=64 to podman it gives me
"OCI permission denied" error, even when my host setting (256) is greater
than requested value.
Thanks,
-- 
Micvhael Ivanov

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io

The way you attempted is correct. Might not be allowed for rootless containers.

I attempted this in a rootful container and it blows up for me.


podman run  --sysctl fs.mqueue.msg_size=64 alpine echo hi
Error: crun: open `/proc/sys/fs/mqueue/msg_size`: No such file or directory: OCI runtime attempted to invoke a command that was not found


_______________________________________________
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