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