Roger Leigh wrote:
> Bob Proulx wrote:
> > There are two issues. ...
>
> So one key question here: do you have /proc mounted inside the
> chroot?
No. I only do that if the task and applications I am running in the
chroot require it. But for my typical chroot these are rarely
required. Sure they are required to run Chromium, required to run
Apache, required to run a long list of things. But they have never
been required to compile a program for example. Being able to compile
using a specified environment is my usual need for specific
environments.
> That's required by ischroot to detect that it's in a chroot;
Apparently. But I call that a bug since it seems remarkably
insufficient to determine if the process is running in a chroot.
Having or not having /proc mounted isn't related to whether the root
directory of the calling process has been changed to a different root
directory. In practice I think that if there isn't a /proc mounted
then that would be a pretty strong indication that a chroot is in
effect.
Traditional Unix filesystems including ext{2,3,4} set the inode of the
root filesystem to 2. Inodes are uniquely numbered over the
filesystem. When a chroot has changed root to a different directory
then the root inode will be a number other than 2. That has been the
only sure way to know if the process is in a chroot. However I do not
know if all filesystems behave that way and I would bet that they do
not and therefore that test would be insufficient on other
filesystems. Those are the most common for root filesystems though
and using that test on those filesystems would be correct.
> but more importantly, it's required for lots of things to work
> properly, including libc, so it's something which is expected to be
> present.
I am not disagreeing that if we look at the sum total of all code
everywhere that a system expects to have various parts available. But
in the simple case for example of creating a chroot for compiling
software and other simple tasks there hasn't previously been a
requirement for having /proc or other extras mounted. If things are
moved to require it then I think that is a very bad direction of
movement. It makes things that would otherwise be very simple much
more complicated. That is bad.
Note that I did specify a policy-rc.d script to disallow running any
daemons other than those listed in the example.
So I do disagree that a simple chroot requires /proc. It never needed
it for Squeeze. If it has become so now then that is a terrible
misfeature and should be improved so as not to require it anymore.
> Note that it's also used by package maintainer scripts, so
> during an upgrade, it's also required.
Other than the 'initscripts' package what others in the basic
debootstrap related packages require it?
I think it is unfortunate to the point of being a bug that initscripts
has this dependency. Fortunately it is only during an upgrade and it
seems to work okay subsequently without it. So I only need to bridge
the gap of an upgrade. It definitely goes in my documentation of
special handling that is required for an upgrade.
I understand that Chromium, Apache, others, need /proc and other
extras. I am not disputing the long list of packages in the entire
repository. But in the basic system there hasn't been a need for it
previously. I am talking debootstrapping a basic installation and
installing basic things like build-essential. And I think that
includes the entire history of Unix-like systems since the early days.
I have been using chroots for a very long time. It is a very useful
feature.
> > And I know that the /run transition was
> > discussed at length in debian-devel. Unfortunately I wasn't following
> > it then and only run into this problem now. I think using bind mounts
> > in either of the two cases is an unfortunate choice. I *really*
> > dislike it. So for me one issue is that the transition uses bind
> > mounts at all. But I am still investigating. I haven't figured out
> > why initscripts takes two different paths depending upon being in a
> > chroot or not. I think that is the root cause of the problem.
> > Whatever it decides to do it should to the same thing in either case.
>
> The reason for the bind mounts. We are migrating:
> /var/run -> /run
> /var/lock -> /run/lock
> /dev/shm -> /run/shm
> /lib/init/rw -> [removed]
> We are also doing this on a live system. We can't move the locations
> except at boot time, but we want it to be functional as soon as
> initscripts is configured. Then packages can simply Depend on
> (initscripts >= $version) and get a functional /run. So it works in
> two stages:
> 1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any
> programs with open files on these filesystems will be unaffected.
> Programs can use both the old and new paths without problems.
> 2) On reboot, mount a tmpfs on /run and replace these directories
> with symlinks. Programs can use both the old and new paths.
> This works very well. See
> http://wiki.debian.org/ReleaseGoals/RunDirectory
> for the detail.
Thank you very much for that nice summary! It helps me a lot.
> However, it won't work in a chroot: chroots don't run init scripts at
> boot, so on reboot, the bind mounts will be lost and the migration
> won't complete.
And in the case of a simple chroot the bind mounts make the
directories "busy" and create a sumbling block. Until the system is
rebooted and then things return to a non-blocked state. But of course
then the /run related dirs need to be fixed up.
> chroots are a special case, and because we can't
> move the directories while they might be in use, we have to adopt a
> different strategy. See the latest initscripts postinst in unstable
> for what we have to deal with.
I will read through them.
> It's really nasty; but we don't have a choice.
You always have choices. You may not like the current ones. There
will always be possibilities you have not thought of yet. They are
many and uncountable.
Perhaps a better statement would be that among the choices considered
the least objectionable choice was taken.
> We also have little control over what parts of the host
> system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need
> to take extra special care never to modify them, lest we break the
> host system.
Agreed.
> One thing we could do here is check if /proc is mounted with
> "mountpoint -q", and then assume we're in a chroot if it fails,
> since having /proc not mounted is very unlikely on the host system.
Yes. That would definitely improve things.
At the least if ischroot returns an error then you know there is
already problem with the postinst assumptions. That case is
definitely not handled correctly.
> However, it will need careful consideration, since the chroots are
> the special case here--we never want to run the special case setup
> for a chroot on the host system unintentionally. "Unlikely" isn't
> a good enough guarantee here--we need to be absolutely certain.
Given the choice between host system breakage and chroot system
breakage I would of course always choose breaking the chroot over
breaking the host system.
But if that is a possibility to break something then improved
documentation in the form of yet another critical package NEWS item
should explain the reason for the breakage and what needs to be done
to work around it.
Bob
Attachment:
signature.asc
Description: Digital signature