[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Get rid of /etc/mtab ?

Martijn van Oosterhout <kleptog@svana.org> writes:

> On Mon, Jul 29, 2002 at 10:22:02AM +0200, Goswin Brederlow wrote:
> > Matthew Garrett <mgarrett@chiark.greenend.org.uk> writes:
> > 
> > > In chiark.mail.debian.devel, you wrote:
> > > 
> > > >/proc/mount should reflect the systems state and with devfs enabled
> > > >but not used the entry is just broken.
> > > 
> > > So should typing "mount -t devfs devfs /devfs" change /proc/mounts, or
> > > only "mount -t devfs devfs /dev"? If I mount devfs inside a chroot,
> > > should /proc use devfs or traditional names? Howabout a /proc inside the
> > > chroot?
> > 
> > Idealy /proc/mounts should change. In a chroot /proc/mounts should
> > also only contain entries inside the chroot and relative to it.
> So the contents of /proc/mounts should change depending on the root
> directory of the process reading it? That sounds like a recipe for
> disaster. Imagine a cdrom mounted outside the chroot. Inside the chroot that

proc already depends on the / of the process looking:

chrot chroot /bin/sh
cd /proc
sh-2.05b# ls -l 1/root
ls: cannot read symbolic link 1/root: Permission denied
lrwxrwxrwx    1 root     root            0 Jul 30 08:28 1/root
sh-2.05b# ls -l self/root
lrwxrwxrwx    1 root     root            0 Jul 30 08:28 self/root -> /

init's root is outside the chroot so I can't read it. Prevents me from
chrooting to inits root to escape my jail.

> would be invisible yet the drive will not open. If an umount /dev/cdrom is
> executed within the chroot, should the kernel fail it?

If you have a /dev/cdrom I would say its inside the chroot but the
mountpoint should be marked as non existent.

Otherwise df gets confused just as with a broken mtab.
> I still maintain that /etc/mtab and /proc/mounts serve completely different
> purposes and trying to merge them will just cause problems.
> What if a secure filesystem needed a keyfile to authorise mounting and other
> things. mount could store the name of that file. Should the kernel store
> that name also in /proc/mounts. If the kernel never needs the file but it's
> all handled by a userspace process, why burden the kernel with it?

Thats what the fstab is for.

> > But asking /proc/mount to change when something is mounted on /dev is
> > probably too much to ask. The layout of the new /dev (you could mount
> > anything there) could be completly random and/or incomplete. Should
> > the kernel not show entries because your missing device nodes? One
> > could make an exception for devfs on /dev probably but who would write
> > the code?
> Say I decide to go against the grain and rename my /dev directory to
> /devices. Now /proc/mounts will be completely wrong, as you state. However,
> /etc/mtab will contain the proper device names.

If you mount and then rename your mtab is broken.
If you rename and then mount both will be right.

Also /etc/mtab breaks when mounting things relative:

%cd chroot
%mount proc -t proc /proc
%cat /etc/mtab
proc proc proc rw 0 0
df: `proc': No such file or directory
% cat /proc/mounts 
proc /mnt/debian/chroot/proc proc rw 0 0

/proc/mounts on the other hand is correct.

Its not a perfect world.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: