Hello Simon, Simon McVittie [2016-10-26 18:40 +0100]: > > Would you be okay with putting [eofcat] into /tmp instead? We wouldn't > > need another mount for this, and autopkgtest itself is already relying > > on /tmp/ carrying executable scripts as it puts autopkgtest-reboot > > (and friends) there. > > That's fine
OK, I pushed this, it passes the tests and works fine with tests/testpkg-reboot: https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=962350c16 > if /tmp mounted noexec is explicitly a non-goal. I wouldn't call it a declared on-goal, but right now exec /tmp is an assumption -- it's the weakest one that autopkgtest can make across all supported backends. There are targets where you don't have root/sudo privileges, or AppArmor/SELinux restricted ones where you might not be able to do mounts (e. g. unprivileged containers). I. e. as long as autopkgtest itself writes scripts to /tmp, we can also do that in virt-qemu. > I had initially made /run/autopkgtest be the shared filesystem mount > point, but I think I prefer using /run/autopkgtest/shared, so that we > have the option of populating the rest of /run/autopkgtest/ with an > executable tmpfs (as in my currently proposed patches) if noexec > /tmp becomes a desired thing to support. Indeed, sounds good! > > So for those cases where you want to explicitly "undermine" the r/o > > file system, I would rather recommend to add > > > > --setup-commands 'mount -o remount,rw /' > > > > to the autopkgtest command line, to keep this explicit. > > Unfortunately that doesn't work with autopkgtest -U (or other interesting > setup commands), because the upgrade-before-testing causes a reboot, and > there doesn't seem to be a hook point to run setup commands after each > reboot; so installing the test dependencies fails. (One of my tests also > does some reboots internally.) Ah, bummer. > Is a --per-boot-setup-commands something you'd consider? I guess it's either that, or a more specific option to remount root r/w at every boot; TBH I'm not too fond of the latter, as it's a bit too specific. --setup-commands-boot sounds more universal/flexible to me. I won't get to that today and I'm on a sprint next week, but I figure I might be able to hack on that while travelling on Sunday. If you want to beat me to it, be my guest of course ☺ Thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)