Subject: Re: PR 36963
To: Jan Danielsson <email@example.com>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 09/20/2007 17:28:52
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 20, 2007 at 03:54:38PM +0200, Jan Danielsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> > 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. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----