Subject: Re: PR 36963
To: Jan Danielsson <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 09/20/2007 17:28:52
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 20, 2007 at 03:54:38PM +0200, Jan Danielsson wrote:
> Hash: SHA512
> Thor Lancelot Simon wrote:
> >>> Oh.  That device's aliased outside the chroot, too, in the original /=
> >>> And init might have a reference to it, too, if it's the console.
> >> Does login in via ssh and exiting cause the same changes?=20
> >=20
> > Hm.  Here's a thought: if he's logging in on the console, init might be
> > using a a file descriptor bound to the device node _outside_ the chroot.
> > I can think of a few ways chaos could then ensue, given subtle bugs in
> > the session-handling or device alias detection code...
>    By "chaos", do you mean "what you are currently seeing", or do you
> mean "everything will be fubar Any Time Now"?

I'm not Thor (nor do I play one on TV), but I suspect something more akin=
to "what you are currently seeing".

> > This kind of problem is why I've never been comfortable having init do
> > the chroot for this sort of system configuration, FWIW.
>    Let's for a moment assume that I didn't know it was a bad idea to use
> init.root, and let's also assume that I'm kind of stuck with it now. Is
> there any hope of fixing it?

Hope? Yes. We have to figure out what's wrong though. ;-)

Since it seems to be the statvfs path munging code that's at issue, try=20
putting printf()s in it indicating what's going on.

As a total aside, I think that code is questionable in this case. The idea=
behind it is (I think) to hide mount points that aren't in the chroot, and=
to not leak info about the chroot path.

As I understand this case, though, your chroot is the mount point.  :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)