On Sun, Jun 30, 2024 at 03:57:40PM -0400, Peter Colberg wrote:
> > Nearly all of them fail in the way quoted below, I haven't figured out where
> > these log errors come from: """logger: send message failed: Operation not
> > permitted""" while running `create-normal-user`.
>
> I encountered this issue with autopkgtest-virt-podman (5.35~bpo12+1)
> in a KVM. While I did not debug the root cause yet,
The permission error is triggered by logger's --id option:
podman exec "$container" strace -f adduser --disabled-login --gecos
"Temporary autopkgtest user,,," test
[pid 370] execve("/bin/logger", ["logger", "--id=369", "--tag=adduser",
"--priority=user.crit", "", "--", "The user `test' already exists."],
0x55efa22252d0 /* 7 vars */) = 0
When specifying an existing process, this fails in podman:
podman exec "$container" logger --id=1 Testing
logger: send message failed: Operation not permitted
See also https://github.com/jonathanio/update-systemd-resolved/issues/25
I believe the permission is CAP_SYS_ADMIN; from capabilities(7):
> forge PID when passing socket credentials via UNIX domain sockets;
Starting the container with CAP_SYS_ADMIN resolves the issue:
container=$(podman run --cap-add=sys_admin --detach=true
autopkgtest/systemd/debian:sid /sbin/init)
podman exec "$container" logger --id=1 Testing
podman exec "$container" journalctl -n 1
Jun 30 21:05:38 d31b39f4ebbc root[1]: Testing
Running autopkgtest with CAP_SYS_ADMIN:
autopkgtest-build-podman --image=debian:sid --init=systemd
autopkgtest -- podman --init autopkgtest/systemd/debian:sid
--cap-add=sys_admin
I am unsure whether this should be considered a bug in adduser; if not,
if adduser is correct in assuming CAP_SYS_ADMIN, dropping adduser from
create-normal-user and always using useradd seems a reasonable solution.
Thanks,
Peter
