Bug#770275: nspawn units a bit hard to get working
Joey Hess
id at joeyh.name
Thu Nov 20 06:33:25 GMT 2014
Package: systemd
Version: 215-5+b1
Severity: normal
A few problems with using systemd-nspawn@$foo.service units on Debian:
* /var/lib/container doesn't exist, so the admin will have to make
the directory in order to put containers where systemd expects to find
them.
If the admin does make the directory, they'll probably make it mode
755 or something. But this allows local users to do eg, hard link
farming to gather suid executables to exploit later, that would
otherwise not be available but might be lying around in some poorly
maintained containers.
So, I think the debian package should create the directory with an
appropriate locked down mode like 700. (Which works fine.)
* Once a nspawn unit is enabled and started, it will fail to run.
This is because persistent journaling is not enabled by default,
and the default for the service file is to use --link-journal=guest,
which doesn't work w/o at least the journal directory existing
(I don't know if it works when the directory exists but persistent
journaling is otherwise disabled.
Workaround: Edit the service file (or override the ExecStart line)
to remove that switch after systemctl enable creates the file.
It seems to me that --link-journal=auto would be a better value.
--
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20141120/5a10f66b/attachment.sig>
More information about the Pkg-systemd-maintainers
mailing list