Re: FW: Symbolic link with absolute target path in UDF - not working properly?

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Dec 13, 2011 at 11:41:20PM +0100, Joerg Schilling wrote:

> lofs has been introduced with NSE, the first project oriented revision control 
> system (based on SCCS). lofs at that time was used to create chrooted tailored 
> environments and of course, symlinks are important in such environments.
> 
> Absolute symlinks in such an environment either point to a local equivalent or 
> they do not point to anything. Both is accepted behavior as this does not 
> differ from the non-chrooted case.
> 
> Relative symlinks that point outside the chrooted environment are evaluated 
> according to the rules for symlinks and for the root directory.
> 
> I see no can of worms here.

What happens when you chroot into a _subtree_ of that lofs?  How would
that kind of symlink look like to readlink(2) and what would following
it do to you?

> Let me look at the "binding"... I cannot see any advantage compared to loopback 
> mounts. Do you know such an advantage?

Why, yes - I do.  A bunch of those.
	* lack of coherency issues; we don't get to deal with separate set
of vnodes as Solaris does.
	* our variant is actually lighter, both in terms of memory
consumption and in runtime overhead.
	* it's conceptually simpler - there is (as in any Unix) a forest of
directory trees (one for each active fs) and there is a mount tree that
glues a unified namespace out of their pieces.  Each node in that tree bears
an arbitrary subtree of some active fs.  mount --bind simply creates a new
mount node refering to subtree rooted at given directory (or a non-directory,
while we are at it, in which case we want the mountpoint to be a non-directory
as well).
	* it plays well with namespaces - just make the mount tree
a property of process, just as the descriptor table, cwd/root, address
space, etc., with the only difference being that fork(2) shares that
one instead of copying; clone(2) does allow creating a copy (so does
unshare(2)).  That's a lot cleaner than chroot, BTW, and being able
to put a part of fs into such environment without plopping the whole
tree into it is very convenient.

> point related symlinks. Given the fact that the Rock Ridge filesystem is older 
> than Linux and that RR introduced mount point related absolute symlinks, isn't 
> this bind mount something that could have been avoided?
> 
> Well, I have to admit that Solaris does not implement mount point related 
> absolute paths in symlinks with Rock Ridge even though it could be done.
> Seems like I should write than code ;-)

Seems like somebody in Sun had enough taste to say "no, thanks" to that kind
of kludge, actually, but don't let that stop you - not our kernel, not our
headache and all such...

FWIW, mount --bind is loosely based on Plan 9 bind(8).  There are differences
in semantics (their variant leads to possibility of infinite mount trees,
which is _not_ something gracefully dealt with by existing Unix codebase)
and implementation differs as well, but the basic idea comes from there.