On Sat, 3 Jun 2000, Jamie Lokier wrote:
> Conceptually in f_vfsmnt. Sure, it's implemented as a parallel tree
> structure. But it's not well hidden. All the VFS operations on names
> have to know about both trees. This is added complexity. Witness the
s/have to know/win from knowledge/. We could ignore the vfsmount almost
everywhere (as the matter of fact, earlier versions did exactly that,
lookup_dentry() just dropped nd->mnt and that was it), but if we actually
postpone the mntput() we win a lot - we can tell whether the dentry tree
is busy or not without doing any walk, just looking at the ->mnt_count.
> recent bug in open_namei() :-)
My fault. Following mounts on the last step is conceptually the same as
following symlinks - same policy should be in place and in fact it is.
I've fscked up with open_namei() - back when I was doing that part of work
I had non-directory bindings in mind, but... not on the surface ;-<
> And I don't like the way you simply can't detect them. (But I suppose
> that's a feature, because the complaint about autofs using symlinks is
> due to programs that explicitly test for symlinks and treat them
> differently. That's what I meant by suggesting a semantic extension to
> symlinks: symlinks that treat lstat the same as stat).
Umm... You know, I'ld rather have a way to determine whether <foo> is a
mountpoint. That would be useful for things a-la tar(1), find(1), etc. -
->st_dev comparison is a kludge, after all the question is about one
point in namespace, not two. OTOH bits in ->st_mode are scarce...
As for the symlinks - you are missing another problem: .. handling. Shell
somewhat hides it, but it makes things even uglier when you get
$ ls ..
bin dev home lost+found mnt proc sbin usr
boot etc lib misc opt root tmp var
$ cd ..
$ ls bin
ls: bin: No such file or directory
IMO security-concerned stuff should treat mountpoints the same way it
treats symlinks. Notice that bindings _are_ mountpoints in all respects
and if you bind the root of filesystem tree you can't distinguish that
from the case when you simply mounted that fs twice - it will give you
exactly the same state. And treatment of mountpoints might be nicer, to
put it mildly - rm -rf crossing the mountpoints hardly made anyone
happy ;-/
-
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 : Wed Jun 07 2000 - 21:00:17 EST