Bug#545691: diverting telinit

[Manoj Srivastava]

Hi,

        I am pulling this discussion off 545691@... and on
 to the devel list, in case it has broader interest. The issue was that
 a maintainer script called telinit to communicate with init, and that
 does not work when the kernel has been started with
 'init=/bin/bash'. (qemubuilder was impacted in the bug, but this might
 need a general fix).

        I created a elaborate test case tos ee if we are in a chroot, if
 not if /proc/1 is actually /sbin/init, and that telinit exists (example
 below).

        Does this need discussion?

        manoj

 if [ -x /sbin/init ] && [ -d /proc/1 ] &&
     [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 2>/dev/null)" ] ; then
     # So, init exists, and there is a linuxy /proc, and the inode of
     # the executable of the process with uid 1 is the same as
     # /sbin/init (ok, no init=/bin/sh going on)

     if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
         # the devicenumber/inode pair of / is the same as that of
         # /sbin/init's root, so we're *not* in a chroot

         # Final sanity check. Make sure there is a /dev/initctl
         # for us to talk to
         if [ -e /dev/initctl ]; then
             # Use telinit if available, it is better form, according
             # to the sysvinit maintainer.
             if [ -x /sbin/telinit ]; then
                 (telinit u ; sleep 1)
             else
                 (init u ; sleep 1)
             fi
         fi
     fi
 fi

--
Whether in the village or the forest, whether on high ground or low,
wherever the enlightened live, that is a delightful spot. 98
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Brian M. Carlson]

On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:

>  if [ -x /sbin/init ] && [ -d /proc/1 ] &&
>      [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 2>/dev/null)" ] ; then
>      # So, init exists, and there is a linuxy /proc, and the inode of
>      # the executable of the process with uid 1 is the same as
>      # /sbin/init (ok, no init=/bin/sh going on)
>
>      if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
>          # the devicenumber/inode pair of / is the same as that of
>          # /sbin/init's root, so we're *not* in a chroot
>
>          # Final sanity check. Make sure there is a /dev/initctl
>          # for us to talk to
>          if [ -e /dev/initctl ]; then

Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
think it's something like /etc/.initctl.  They do, however, have a
linuxy proc.  You should probably check with the porters as to what
location is appropriate on those architectures.

--
brian m. carlson / brian with sandals: Houston, Texas, US
[phone] | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[Manoj Srivastava]

On Fri, Oct 23 2009, brian m. carlson wrote:

> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>>  if [ -x /sbin/init ] && [ -d /proc/1 ] &&
>>      [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe 2>/dev/null)" ] ; then
>>      # So, init exists, and there is a linuxy /proc, and the inode of
>>      # the executable of the process with uid 1 is the same as
>>      # /sbin/init (ok, no init=/bin/sh going on)
>>
>>      if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
>>          # the devicenumber/inode pair of / is the same as that of
>>          # /sbin/init's root, so we're *not* in a chroot
>>
>>          # Final sanity check. Make sure there is a /dev/initctl
>>          # for us to talk to
>>          if [ -e /dev/initctl ]; then
>
> Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
> think it's something like /etc/.initctl.  They do, however, have a
> linuxy proc.  You should probably check with the porters as to what
> location is appropriate on those architectures.

        Well, this was not an issue i my case, since these packages do
 not support  ! linux, but yes, a generic solution would have to cater
 to that as well.

        manoj
--
Today is the first day of the rest of the mess.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>         I created a elaborate test case tos ee if we are in a chroot, if
>  not if /proc/1 is actually /sbin/init, and that telinit exists (example
>  below).

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.

>         Does this need discussion?

Yes, it is highly sysvinit and Linux specific.

Bastian

--
Four thousand throats may be cut in one night by a running man.
                -- Klingon Soldier, "Day of the Dove", stardate unknown


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Mon, Oct 26, 2009 at 10:40:56AM +0100, Bastian Blank wrote:
> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
> >         I created a elaborate test case tos ee if we are in a chroot, if
> >  not if /proc/1 is actually /sbin/init, and that telinit exists (example
> >  below).
> 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.

Oh, and this could be made even easier by defining file-based triggers
in the package providing init instead of doing it in all the
dependencies.

Bastian

--
Phasers locked on target, Captain.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Oct 26 2009, Bastian Blank wrote:

> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>>         I created a elaborate test case tos ee if we are in a chroot, if
>>  not if /proc/1 is actually /sbin/init, and that telinit exists (example
>>  below).
>
> 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). Especially if the  changes impact the ability
 to load the security policy in the first place.  Just take it that
 there may be cases where it is better to abort the install rather than
 not re-exec init.


>>         Does this need discussion?

> Yes, it is highly sysvinit and Linux specific.

        The solution was. But this is not a generic solution in the
 first place. What we have is a potential issue, which was solved in a
 particular manner for specific packages. If this issue  has broader
 impact, a more generic solution will be needed. Whic brings us to the
 raison d'etre  for this thread.

        manoj
--
Two sure ways to tell a REALLY sexy man; the first is, he has a bad
memory. I forget the second.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Oct 26 2009, Bastian Blank wrote:

> On Mon, Oct 26, 2009 at 10:40:56AM +0100, Bastian Blank wrote:
>> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
>> >         I created a elaborate test case tos ee if we are in a chroot, if
>> >  not if /proc/1 is actually /sbin/init, and that telinit exists (example
>> >  below).
>> 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.
>
> Oh, and this could be made even easier by defining file-based triggers
> in the package providing init instead of doing it in all the
> dependencies.

        In which case it definitely deserves discussion, some
 coordination, and perhaps a policy proposal, as well as a more generic
 solution. Which files would we be triggering on?

        manoj
--
Logic is the chastity belt of the mind!
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

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. Selinux can only be activated on boot anyway.

Bastian

--
Intuition, however illogical, is recognized as a command prerogative.
                -- Kirk, "Obsession", stardate 3620.7


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

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).

> 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).

        manoj
--
There are more old drunkards than old doctors.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bill Allombert-3]

On Mon, Oct 26, 2009 at 07:23:12AM -0500, Manoj Srivastava wrote:

> On Mon, Oct 26 2009, Bastian Blank wrote:
>
> > On Mon, Oct 26, 2009 at 10:40:56AM +0100, Bastian Blank wrote:
> >> On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote:
> >> >         I created a elaborate test case tos ee if we are in a chroot, if
> >> >  not if /proc/1 is actually /sbin/init, and that telinit exists (example
> >> >  below).
> >> 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.
> >
> > Oh, and this could be made even easier by defining file-based triggers
> > in the package providing init instead of doing it in all the
> > dependencies.
>
>         In which case it definitely deserves discussion, some
>  coordination, and perhaps a policy proposal, as well as a more generic
>  solution. Which files would we be triggering on?

No file would. Instead packages postint would use dpkg-trigger to activate
the trigger and let the package providing the trigger deal with it.

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

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-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Mon, Oct 26, 2009 at 07:23:12AM -0500, Manoj Srivastava wrote:
> On Mon, Oct 26 2009, Bastian Blank wrote:
> > Oh, and this could be made even easier by defining file-based triggers
> > in the package providing init instead of doing it in all the
> > dependencies.
>         In which case it definitely deserves discussion, some
>  coordination, and perhaps a policy proposal, as well as a more generic
>  solution. Which files would we be triggering on?

The used libs.

Bastian

--
Landru! Guide us!
                -- A Beta 3-oid, "The Return of the Archons", stardate 3157.4


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Oct 26 2009, Bastian Blank wrote:

> Policy is not coupled with init or the libs. This is a problem between
> the kernel and the policy tools.

        This is not totally true: init loads the initial policy, and
 that means that linking with new versions of selinux libs makes a
 difference at startup. It is, however, irrelevant for upgrades --
 unless changes in the future libsepol and/or libselinux   and init
 expand init's role in security.

        Which is why currently, as I  have said before, re-execing init
 is opportunistic.  This may or may not be the case in the future.

        Am I not getting through, somehow? Have I not re-iterated that
 the current situation does not absolutely require init to be re-exec'd,
 but it is not unfathomable that it might be in the future? And that
 potential is why I brought it up in the first place?

        Anyway, I am done addressing this red herring, shiny thought it be.

        manoj
--
[Crash programs] fail because they are based on the theory that, with
nine women pregnant, you can get a baby a month.  -- Wernher von Braun
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Mon, Oct 26, 2009 at 01:28:33PM -0500, Manoj Srivastava wrote:
> On Mon, Oct 26 2009, Bastian Blank wrote:
> > Policy is not coupled with init or the libs. This is a problem between
> > the kernel and the policy tools.
>         This is not totally true: init loads the initial policy, and
>  that means that linking with new versions of selinux libs makes a
>  difference at startup. It is, however, irrelevant for upgrades --

We are currently speaking about upgrades. And I doubt that init have the
permission to load the policy again after transiting away from the
initial startup role.

>         Which is why currently, as I  have said before, re-execing init
>  is opportunistic.  This may or may not be the case in the future.

No. It is not. All the re-exec init calles are only to start it with
new libs and there is no change visible for that role.

Bastian

--
In the strict scientific sense we all feed on death -- even vegetarians.
                -- Spock, "Wolf in the Fold", stardate 3615.4


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russell Coker]

On Tue, 27 Oct 2009, Bastian Blank <waldi@...> wrote:
> >         Which is why currently, as I  have said before, re-execing init
> >  is opportunistic.  This may or may not be the case in the future.
>
> No. It is not. All the re-exec init calles are only to start it with
> new libs and there is no change visible for that role.

Manoj's point is that some future security library may require such
functionality.

It seems that it would always be good to be able to report errors to the
caller regardless of the consequence.  The importance of the error is
determined by the importance of the subsystem which has the error, and
process 1 in Unix is very important!

--
russell@...
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
To UNSUBSCRIBE, email to debian-policy-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Fri, Oct 23, 2009 at 06:43:32PM +0000, brian m. carlson wrote:
> Last I checked, the kfreebsd-* architectures don't use /dev/initctl; I
> think it's something like /etc/.initctl.  They do, however, have a
> linuxy proc.  You should probably check with the porters as to what
> location is appropriate on those architectures.

Huh, isn't that an FHS violation?  /dev/initctl isn't much better, but seems
to be covered by "special files"; upstart doesn't use either of these
locations, fwiw.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...

[Brian M. Carlson]

On Mon, Oct 26, 2009 at 10:56:16PM -0700, Steve Langasek wrote:
> Huh, isn't that an FHS violation?  /dev/initctl isn't much better, but seems
> to be covered by "special files"; upstart doesn't use either of these
> locations, fwiw.

I think the issue came down to the fact that with kFreeBSD, /dev is a
devfs, which cannot handle FIFOs, only block and character nodes and
symlinks.  I don't even know if that's still the case; my only kFreeBSD
machine was moved back to Linux due to some problems with the earlier
versions of kFreeBSD, like bind9 not working.

--
brian m. carlson / brian with sandals: Houston, Texas, US
[phone] | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187