Hi Lennart, thank you very much for reviewing and responding to the mess I made. Hopefully it will be a smoother experience from now on.
On Mon, 13 Apr 2015 16:08:28 +0200 lennart at poettering.net (Lennart Poettering) wrote: > What kind of containers are these? LXC? docker? I guess I failed describing the scenario properly. I was trying to run a fresh Archlinux installation inside a subdirectory via the systemd-nspawn -b -D ... command on a debian host. No Docker, LXC or any other software was involved. Just plain systemd tools and a bio blob between chair and keyboard. I was toying around with systemd-nspawn. It seems to me as a smoother implementation of that whole container idea compared to docker for example because it directly boots into systemd and properly initializes services and other environment related resources like the machine-id file within /etc/. It's also quiet nice to have systemd to handle the init daemon and logging tasks. The other solutions leave you on your own here. > nspawn at least grants audit caps to containers. If you don't grant > audit caps you cannot boot distros like Fedora at all, since much of > the PAM audit code in Fedora is written to fail completely if audit > is on in the kernel, but cannot be used. My first impression was that container/namespaces aren't supported inside the audit kernel code at all. Someone at the #archlinux channel on freenode gave this hint and I also thought this way because the kernel source at <https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/audit.c?h=linux-3.16.y#n653> looks this way. But at a closer look it doesn't seem to me like that anymore mostly because the returned error at the given line differs from the error I'm experiencing (ECONNREFUSED vs. EPERM). It rather seems that the "offending" line is <https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/audit.c?h=linux-3.16.y#n1115>. I still have to butt in though. There are 2 issues here at hand. The first one: It doesn't look to me like the audit subsystem within the kernel is ready for namespaces. They aren't directly rejected but I can't see any measurements to separate namespaces. It would be quiet unfortunate if processes within a namespace could receive audit events from another namespace. The second problem is rather simple: it seems libcap currently doesn't understand the CAP_AUDIT_READ value so passing it to the --capability= option is not an (easy) option. Given that I would suggest to treat the whole audit subsystem to be optional and don't fail too hard if it can't be used. Unfortunately pre-built packages can't offer the option to configure this behavior. > Hmm, exluding the audit code from the build if HAVE_AUDIT is not set > is certainly a good idea, but we generally try to keep #ifdeffery out > of .c files. More specifically, the journald-audit.c file should not > be compiled and linked at all on non-audit builds, and > journald-audit.h should contain the #ifdeffery that causes > server_open_audit() to become a NOP on such builds. Would be happy to > take a patch for that. Can't agree more with you here. Your solution to the problem is a little more work than I was initially willing to invest into the problem. I'll gladly provide a better patch for this given the the interest in handling this. Thank you very much for reading this lengthy mail, I'm looking forward to your response! Greetings, Frank. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
