| 2014-03-27 18:04:43 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2014-03-27 18:06:53 |
Marc Deslauriers |
bug |
|
|
added subscriber Marc Deslauriers |
| 2014-03-27 18:28:24 |
Jamie Strandboge |
description |
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 |
apparmor's sysv initscript starting late has security implications because applications that are confined and 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 |
|
| 2014-03-27 18:28:54 |
Jamie Strandboge |
description |
apparmor's sysv initscript starting late has security implications because applications that are confined and 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 |
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 |
|
| 2014-03-27 19:10:37 |
Steve Beattie |
bug |
|
|
added subscriber Steve Beattie |
| 2014-04-08 22:11:37 |
Jamie Strandboge |
tags |
|
rls-t-incoming |
|
| 2014-04-09 14:44:32 |
Jamie Strandboge |
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 |
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 |
|
| 2014-04-09 14:45:47 |
Jamie Strandboge |
information type |
Public Security |
Public |
|
