Hi, Quoting Martin Pitt (2016-11-16 16:17:29) > Johannes Schauer [2016-11-16 14:13 +0100]: > > Unfortunately, I was unable to achieve the same I'm currently doing with > > lxc-usernsexec and lxc-unshare with unshare and nsenter. > > Interesting; now you sparked my curiosity :-) Do you happen to > remember the details what isn't working?
some archaeology from my side would be required to try to recover my attempts from the past (as long as one year ago). Some of the problems are documented here: https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/ For example, most notably, "mount -t proc proc /proc" never worked without doing the systemcalls manually using the perl script I present there. This problem of course might also have been due to remaining bugs in the tools I used (including my kernel) which are long fixed now. Though the fact that the last line in that post still throws an error indicates otherwise: lxc-usernsexec -m b:0:1000:1 -m b:1:558752:1 -- unshare --mount-proc=/tmp/buildroot/proc --ipc --pid --net --uts --mount --fork -- true unshare: mount /tmp/buildroot/proc failed: Invalid argument > > Despite reports claiming otherwise, I never got lxc to run without superuser > > privileges. Is it easier with lxd? > > It's not hard to do, but indeed "classic" LXC hasn't really been > designed for that from the start. Unprivileged containers are the > default mode of operation for lxd, so it's literally "sudo apt install > lxd", "sudo lxd init"(to set up its bridge, basically pecking on Enter > 20 times), then "autopkgtest my-package/ -- lxd images:debian/sid/amd64" > works as normal user. Wow, that's awesome! Now I'm wondering whether uchroot is still useful if there is just some packaging of another piece of software that's missing. > Right, that's why I think it should exclude /dev wholesale, and then the code > below makes sure to construct a known-working and minimal /dev. Can also be done. > > That can be done. It will just not be used by sbuild because sbuild makes > > no requirements for the backend to provide that functionality and thus > > "squeezes everything through a pape" independent of the backend. > > That's got nothing to do with sbuild -- this is just internal > communication between teh "autopkgtest" controller process on the host > (which has the initial package) and the virt backend in the testbed > (which receives the tests, and sends back results). Of course. It just has something to do with sbuild for me, because my motivation to write this backend is because I want to run sbuild without superuser privileges. > > I have another autopkgtest-specific question. Currently, when using this > > code with sbuild and I hit Ctrl+C to send a SIGINT, it appears as if > > autopkgtest would immediately call hook_cleanup(). Can that be? How do I > > prevent that from happening? It only happens with my uchroot backend and > > not any other, so I'm probably doing something wrong. Trapping SIGINT in > > the shell script doesn't seem to have any effect. > > Right, lib/VirtSubproc.py does that in prepare(). The idea was that ^C > would cleanly shut down the virt runner, then the frontend > (autopkgtest) would notice and do its cleanup part. > > How is calling hook_cleanup() not working/not enough for uchroot? We can > certainly make that more flexible if needed. Then I still don't understand something. In sbuild, when I hit ^C, the autopkgtest schroot backend does not seem to get closed immediately because sbuild is still doing some cleanup stuff before sending the "close" command to autopkgtest. But with the autopkgtest uchroot backend, the hook_cleanup() seems to get immediately called after my ^C, thus the cleanup code will fail and the "close" command will be futile because the autopkgtest pipe does not even exist anymore at that point. So I don't understand this difference in behaviour. Thanks! cheers, josch
signature.asc
Description: signature
