[Bug 925513] Re: plymouth should not run in container

[Serge Hallyn]

Quoting Steve Langasek (steve.langasek at canonical.com):
> On Thu, Feb 16, 2012 at 02:25:36PM -0000, Serge Hallyn wrote:
> > regarding whether disabling plymouth is the right fix:  I don't know the
> > mechanisms plymouth uses.
> 
> Well, I'm happy to answer questions you have on this, but I don't understand
> what issue you're trying to address by disabling plymouth.  The bug
> description says only that:
> 
> > As stgraber said, "it writes some error messages to /var/log/upstart (when
> > you have logging) and sometimes to the console".
> 
> But a) that's not true for values of "it" == "plymouth" (maybe this refers
> to upstart?), and b) it's not clear to me what behavior you expect for the
> various messages if plymouth is disabled - particularly the ones that are
> *actually* being routed to plymouth, which may require some sort of user
> interaction.
> 
> > 1. for system log entries, the right fix will be a syslog namespace,
> > which doesn't yet exist.
> 
> plymouth has nothing to do with syslog.  It captures *console* output to
> /var/log/boot.log, but that's a secondary function and doesn't use syslog
> for output.

Does it write it straight to /var/log/boot.log, or does it do it through
syslog(2) or syslog(3)?  If it writes straight to /var/log/boot.log then
there should be no problem.

> > 2. if it uses proc files, we may be able to use apparmor to protect from
> > plymouth, though that may make plymouth fail and cause the container to
> > not boot right.  The right fix would be a mix of user namespaces and
> > proc file access filtering.
> 
> Plymouth uses /proc/cmdline and /proc/self/fd.  Are these a problem in
> lxc?

/proc/self/fd is correct.  /proc/cmdline will be the host's kernel
cmdline, which shouldn't exactly be a problem but may be misleading.

> > 3. if it uses devices (ioctls or writes), we may be able to use apparmor
> > and/or the devices namespace to protect from plymouth, but a device
> > namespace will be the right fix.
> 
> Oh, it definitely uses devices.  At a minimum, it expects to be able to open
> /dev/console.  It also generally expects to make use of /dev/fb, /dev/tty0,
> /dev/tty1, and a few others.  I had assumed that there is some sort of
> virtualized console in the container that would be exposed with the usual
> device name.  If there isn't, then there's definitely no point in running
> plymouth in a container.

/dev/console and /dev/tty{1-4} are bind-mounted pty devices, and are ok
for it to use.  /dev/fb is not available in the container - I don't see
/dev/fb0 at all, and the devices cgroup will refuse the container the
rights to read or write it.  Otherwise it would be a problem as that is
not virtualized.

Steve, it sounds to me like we should mark this bug as wontfix.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to plymouth in Ubuntu.
https://bugs.launchpad.net/bugs/925513

Title:
  plymouth should not run in container

Status in “lxc” package in Ubuntu:
  Confirmed
Status in “plymouth” package in Ubuntu:
  Incomplete

Bug description:
  Once upstart knows whether it is running in a container, plymouth
  should not run in a container.  As stgraber said, "it writes some
  error messages to /var/log/upstart (when you have logging) and
  sometimes to the console".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/925513/+subscriptions