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
%cd
%df
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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: