[Bug 1298539] Re: apparmor rcS.d sysv initscript is running too late

[Steve Langasek]

Having discussed on IRC, I don't believe /etc/init/rc-sysinit.conf being
delayed explains the symptoms described.  User processes are started
from a login session, which would be launched via lightdm; lightdm is
'start on runlevel and [...]', and the runlevel event is strictly later
than the point at which we run the rcS scripts from rc-sysinit.conf.

If this were processes related to individual upstart jobs in /etc/init
that might start before runlevel 2, then this could explain it; but
given the problem described is with firefox being unconfined, that
doesn't seem related to the delayed apparmor profile loading because
firefox and lightdm are also delayed in that case.

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

Title:
  apparmor rcS.d sysv initscript is running too late

Status in “upstart” package in Ubuntu:
  New

Bug description:
  apparmor's sysv initscript starting late has security implications
  because applications that have apparmor policy defined but don't use
  an upstart job (eg, telepathy-mission-control, tcpdump, evince,
  firefox, etc) may be started before the the sysv init script has a
  chance to load the profiles, resulting in the applications running
  unconfined.

  From IRC:

  12:50 < infinity> jdstrand: Could it be that slangasek's assertion about network interfaces only delaying rc2 is wrong, and it in fact delays all of sysvinit?  That would pretty much explain that paste.
  ...
  12:53 < slangasek> ok, so /etc/init.d/rcS is run from the bottom of /etc/init/rc-sysinit.conf, which does key on static network up
  12:53 < slangasek> I thought we had better interleaving of /etc/rcS.d with the rest of the system
  12:53 < slangasek> jdstrand: so yeah, any late apparmoring that you're seeing is actually related to us having made /etc/rc2.d non-racy, without noticing that this also holds up /etc/rcS.d :/
  12:54 < slangasek> proper fix would be to split out /etc/rcS.d handling, and make it wait for the local filesystem but not the network
  12:54 < infinity> slangasek: So, curious followup.  Why do I have a console?
  12:54 < jdstrand> slangasek: oh! it is great to know the cause
  12:55 < infinity> slangasek: My hvc0 job is "start on stopped rc RUNLEVEL=[2345]", is that basically a complete lie, given how we're running rcS/rc2?
  12:56 < jdstrand> slangasek: since I use network-manager, the fact that I don't see it locally is consistent with your understanding of the issue, correct?
  12:56 < slangasek> jdstrand: correct
  12:57 < jdstrand> I never saw it in a vm cause I almost always do desktop installs in them
  12:57 < slangasek> infinity: ummmm ok, yeah, I don't know why you would have a console with output from rc2.d showing up then
  12:58 < slangasek> infinity: because 'stopped rc RUNLEVEL=[2345]' should mean the console starts only after all of rc2.d is done running
  12:58 < infinity> slangasek: That's what I would think, yes.
  12:58 < jdstrand> slangasek: so, is there something that can be done for 14.04 for this? (like I said, we can't to the cache pregeneration/upstart job change before 14.10/SRU)
  12:59 < infinity> slangasek: And really, while delayed boots are annoying (and they are), the larger complaint is actually that these late starts scribble all over the getty, making it confusingly non-obvious that a login prompt has happened. :P

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