mnt_dirname revisited (chroot)

From: almesber@lrc.di.epfl.ch
Date: Sun Jan 16 2000 - 07:27:46 EST


I wrote:
> There are still some issues with /proc/mounts, because hopping from one
> root to the next obviously wrecks its semantics.

Well, I found an approach to fix this:
 - create directory /proc/mount in which each mount point appears as
   /proc/mount/<kdevname> link. This way, all mount points can be
   reached via proc, independent of the current root. (*)
 - prepend d_path(proc_dir)/mount/kdevname(mnt_sb->s_dev) to the path
   obtained via d_path(mnt_sb->s_root) iff the latter does not end at
   the current process' root

(* I also need to check if the aliasing upsets dcache. I doubt it,
   though.)

Since anybody who reads /<proc>/mounts obviously has /<proc> (which
may of course be at some other place than /proc), this yields valid
path names again. People doing
chroot /somewhere cat /proc/mounts | do_domething
deserve whatever they get ;-)

Subtle problem: constructing the current proc_dir path can be a bit
of a nightmare, because this information is stripped long before
calling get_filesystem_info or such. I'm not convinced fixing
/proc/mounts is really worth this.

A less intrusive, but unfortunately also less elegant approach would
be to prepend the kdevname to /proc/mounts if the path can't be
constructed, and to leave it to the application to figure out what
to do. E.g.
/dev/hda1 /foo ext2 rw 0 0 -> it's on /foo
/dev/hda2 03:03/bar ext2 rw 0 0 -> it's on /proc/mount/03:03/bar
                                   (detection: path doesn't begin with "/")
Since every program reading /proc/mounts knows where /proc is, we
also don't need to encode any such policy in the kernel in this
case.

Disadvantage of the second approach: each application that reads
/proc/mounts needs to be aware of the new convention.

Opinions ? Strong objections to /proc/mount/<kdevname> in general ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH       werner.almesberger@ica.epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:13 EST