Re: Bug#545691: diverting telinit
On Tue, Oct 27 2009, Steve Langasek wrote:
> On Tue, Oct 27, 2009 at 08:17:08AM -0500, Manoj Srivastava wrote:
>
>> >> Not needed. If init has been just upgraded, it has been already
>> >> told to init -u itself.
>
>> > This does not appear to be true for upstart, which it's planned to switch to
>> > on Linux for squeeze.
>
>> Well, I guess we shall have to use other means (invoke-rc.d?)
>> to have upstart re-exec itself. Does upstart provide other means for
>> that?
>
> The question is not whether upstart *can* reexec itself (telinit -u
> does this), the question is whether it *does*, or *should*. It
Well, at this point, upstart is not as well integrated into the
security system as sysvinit is. There is a security imperative for the
re-exec to happen in certain circumstances (more on this below)
> doesn't do this on upgrade, because unlike sysvinit, upstart is also a
> process supervisor and the current version isn't smart enough to not
> preserve job state across re-exec.
> This is a bug, certainly, but as long as upstart isn't re-execing
> itself on upgrades, I don't think other packages should be re-execing
> it either.
As long as the security policy (well, file contexts, really)
have not changed, there is no security downside of upstart not
re-exec'ing itself. But if the file context of upstart changed with a
new security policy, upstart needs to be transitioned into the new
security domain (or the machine needs to be halted/rebooted)
manoj
[Yes, I know, this is a hard-assed attitude to security, but some
people I have worked for require no less. Can't have a non-compliant
machine on campus.]
--
The last time I saw him he was walking down Lover's Lane holding his own
hand. Fred Allen
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: