On Mon, Oct 26, 2009 at 11:22:35AM -0500, Manoj Srivastava wrote:
> On Mon, Oct 26 2009, Bastian Blank wrote:
>
> > On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote:
> >> On Mon, Oct 26 2009, Bastian Blank wrote:
> >> > Why are they not able to ignore the errors from telinit? All checked
> >> > packages uses this to ask init to reexecute itself and free old library
> >> > references. Nothing in this is critical to the usability of the packages
> >> > themself or the system.
> >> Even if the security system has changed? I dont't think so
> >> (better safe than sorry).
> > Which security system? Is there a list of packages trying to reexec
> > init? The listed bugs only show libsepol and libselinux, both do
> > nothing in respect of that.
> So far, I hav not needed to. But I can see where there is a
> major change in libselinux (we are at the same soname so far, so this
> has not happened), and the new libselinux is needed to not have people
> bypass init.d's security setup by exploiting a bug in the old system
> (perhaps a change is needed in libselinux/libsepol to even load new
> policy). If that happens, not being able to re-exec init can be grounds
> for a failure to boot (as it is now if you enable selinux and init
> can't load policy).
Reexec init is only needed to make it change the security domain of
itself. Rules reload would be done somewhere else.
> > Selinux can only be activated on boot anyway.
> What does this have to do with the price of rice in china? The
> scenario of interest is a system with selinux enabled and in enforcing,
> and a upgrade of security libraries (and policy, perhaps).
Policy is not coupled with init or the libs. This is a problem between
the kernel and the policy tools.
I still don't see what you want to tell me.
Bastian
--
Witch! Witch! They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
