On Thu, 1 Jun 2000, Chris Evans wrote:
> Thanks for replying. Thinking about it, it's logical to demand write
> access in parent directory (P).
>
> We are essentially replacing a dentry in P with a totally different
> one. This is semantically equivalent to
>
> mv(old_dentry, backup_dentry)
> mkdir(new_dentry)
>
> And the above sequence certainly requires write permission in P
>
> The only difference is that the mount "bind" case does the above sequence
> atomically.
The sequence above does, indeed, require write permissions on P, but what
stops you from
move everything away from the directory
chmod it
chown if needed
enjoy
Yes, we must check that it's not immutable/append-only (the former already
checked, the latter... OK, needs to be added). But parent?
Look: if we can add/remove on parent the permissions on mountpoint do not
matter at all, because of your scenario. So maybe we need to check the
parent (+ imm/a-o on the mountpoint, as usual) and to fsck with
permissions on the mountpoint...
BTW, bind does something very different - model behind this stuff looks
so: we have a forest of dentry trees and we have a tree of vfsmounts. Each
vfsmount represents the portion of unified tree - it contains the
reference to some point in some dentry tree + reference to
(vfsmout,dentry) of mountpoint. IOW, it's "if you come to
(foo->mnt_parent,foo->mnt_mountpoint) - jump to (foo, foo->mnt_root)" and
"if you go by .. from (foo,foo->mnt) - replace it with
(foo->mnt_parent,foo->mnt_mountpoint) and act as if .. was issued there".
Several vfsmounts may refer the same tree (or parts of the same tree) - we
do not duplicate dentries at all, no matter how many times do you mount
the thing. So dcache coherency comes for free, which was the main reason
behind this scheme (could you spell "exploitable races in case of devfs
being mounted several times"?).
Another thing that we need is recursive bind (-ELOOP if we would create a
loop, indeed). I think that with some care we could do it in userland,
but there may be races. I'm holding this patch until we'll see what the
right API for mount()/mounttrap()/bind-like stuff is - mount(2) is a
living horror and I hate the idea of overloading it even more.
-
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:13 EST