Control: reassign -1 src:passt 0.0~git20240814.61c0b0d-1 Control: affects -1 podman Control: severity -1 serious Control: retitle -1 passt broken on i386, possibly all 32-bit architectures
On Sun, Aug 18, 2024 at 04:47:39PM +0200, Uroš Knupleš wrote: > Using podman in a rootless environment (such as non-root user) on i686 > causes containers to have no networking access when using pasta. > Containers are brought up, but they have no networking. > > Switching networking to slirp4netns seems to alleviate the issue, so > that's a workaround I'm using for now. Thanks, that is a super useful bug report. I've reproduced and confirmed this, and found a bug in passt to be the culrpit. > Interestingly, this kernel message pops up every time an container > is brought up as an non-root user: > > [ 361.611472] audit: type=1326 audit(1723988353.266:23): auid=1000 uid=1000 > gid=1000 ses=1 subj=pasta pid=1394 comm="pasta" exe="/usr/bin/pasta" sig=31 > arch=40000003 syscall=403 compat=0 ip=0xb7fb0579 code=0x80000000 This is indeed the smoking gun. You can parse these messages manually (by looking at audit.h, syscall etc. values in headers), or just install auditd (apt install auditd), and tail /var/log/audit/audit.log. In this case, 1326 is type=SECCOMP, and syscall 403 is "clock_gettime64". It looks like the passt source code includes a shell script, that parses "syscall:" comments and generates seccomp filters for them. (It does not use libseccomp). In this case, there is a comment that states: * #syscalls clock_gettime arm:clock_gettime64 ...but on i386, and likely other 32-bit architectures (like 32-bit arm, which is seemingly already handled), glibc's clock_gettime() is wrapping the clock_gettime64 syscall. Adding i686:clock_gettime64¹ to that line addresses this specific occurence, but moves the goalpost a bit further: after a few iterations, I found that the "fcntl64", "socketcall" and "recvmmsg_time64" also need to be allowlisted. By adjusting source code comments to add these 4 syscalls in their relevant spots and rebuilding passt, I managed to get "podman run --rm -it" to work on i386. Note however that this is a rudimentary test and for example only exercises the "pasta" code path; someone more familiar with passt/pasta should probably verify other code paths as well. It'd be a good idea to involve upstream. Hope this helps! Faidon 1: "i686" because seccomp.sh calls `uname -m` if there is no TARGET specified, which I think is a (cross-)portability bug of its own...