Re: symlink_prefix

Re: symlink_prefix

[Andries.Brouwer]

    From viro@math.psu.edu Sun Jun  3 02:49:08 2001

    On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

    > This evening I needed to work on a filesystem of a non-Linux OS,
    > full of absolute symlinks. After mounting the fs on /mnt, each
    > symlink pointing to /foo/bar in that filesystem should be
    > regarded as pointing to /mnt/foo/bar.
    > 
    > Since doing ls -ld on every component of every pathname was
    > far too slow, I made a small kernel wart, where a mount option
    > -o symlink_prefix=/pathname would cause /pathname to be prepended
    > in front of every absolute symlink in the given filesystem
    > (when the symlink is followed). That works satisfactorily.

    Absolute symlinks... Dunno. _If_ we want that at all, we probably
    want it on per-mountpoint basis. However, that opens a door to
    _really_ ugly feature requests. E.g. "if symlink starts with
    /foo - replace it with /mnt/bar, but if it starts with /foo/baz -
    replace with /mnt/splat instead".

Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
/, /usr and /usr/spool filesystems for FOO OS. Now
	mount /dev/a /mnt -o symlink_prefix=/mnt
	mount /dev/b /mnt/usr -o symlink_prefix=/mnt
	mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt
suffice.
I do not immediately see a realistic use for changing symlink
contents halfway.

    I can see how to implement per-mountpoint variant. However, I'm
    less than enthusiastic about the API side of that and about the
    ugliness it will lead to. It smells like a wrong approach. And
    no, I don't see a good one right now.

    As for the API... How would you pass that option? Yet another
    mount(2) argument?

What I did was: add a field  `char *mnt_symlink_prefix;'  to the
struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
namei.c:vfs_follow_link(). Pick the value up by recognizing
in super.c:do_mount() the option "symlink_prefix=" before
giving the options to the separate filesystems.

[One could start a subdiscussion about that part. The mount(2)
system call needs to transport vfs information and per-fs information.
So far, the vfs information used flag bits only, but sooner or later
we'll want to have strings, and need a vfs_parse_mount_options().
Indeed, many filesystems today have uid= and gid= and umask= options
that might be removed from the individual filesystems and put into vfs.
After all, such options are also useful for (foreign) ext2 filesystems.]


Andries

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> What I did was: add a field  `char *mnt_symlink_prefix;'  to the
> struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
> namei.c:vfs_follow_link(). Pick the value up by recognizing
> in super.c:do_mount() the option "symlink_prefix=" before
> giving the options to the separate filesystems.
> 
> [One could start a subdiscussion about that part. The mount(2)
> system call needs to transport vfs information and per-fs information.
> So far, the vfs information used flag bits only, but sooner or later
> we'll want to have strings, and need a vfs_parse_mount_options().
> Indeed, many filesystems today have uid= and gid= and umask= options
> that might be removed from the individual filesystems and put into vfs.
> After all, such options are also useful for (foreign) ext2 filesystems.]

_Please_, if we do anything of that kind - let's use a new syscall.
Ideally, I'd say
	fs_fd = open("/fs/ext2", O_RDWR);
	/* error -> no such filesystem */
	write(fs_fd. "/dev/sda1", strlen("/dev/sda1"));
	/* error handling */
	write(fs_fd, "reserve=5", strlen(....));
	...
	dir = open("/usr/local", O_DIRECTORY);
	/* error handling */
	new_mount(dir, MNT_SET, fs_fd);	/* closes dir and fs_fd */
	/* error handling */

First open gives you a new channel. Preferably - wit datagram semantics (i.e.
write() boundaries are preserved). Then you convince fs driver to give you
fs. Then you mount it.

Notice that all cruft with "mount ncpfs and then use ioctls to authenticate"
goes away - authentication happens before you mount. Parsers are also easier
that way. Moreover, seeing what filesystem types are available is also trivial,
etc. We need only one special case - mounting that fstypefs. Fine, let's
make new_mount(dir, MNT_TYPES) do that.

BTW, bind and friends are also easy - it's
	what = open(old, 0);
	where = open(mountpoint, 0);
	new_mount(where, MNT_BIND, what);

Comments?

Re: symlink_prefix

[Remi Turk]

On Sun, Jun 03, 2001 at 07:25:25AM -0400, Alexander Viro wrote:
> BTW, bind and friends are also easy - it's
> 	what = open(old, 0);
> 	where = open(mountpoint, 0);
> 	new_mount(where, MNT_BIND, what);
> 
> Comments?

What if `what' and or `where' aren't directories but e.g. sockets?
(IOW, would this allow binding sockets into the filesystem,
or am I being too perverse here?)

Happy Hacking

-- 
Linux 2.4.5-ac6 #2 Sun Jun 3 15:45:27 CEST 2001

Re: symlink_prefix

[Pavel Machek]

Hi!

> > What I did was: add a field  `char *mnt_symlink_prefix;'  to the
> > struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
> > namei.c:vfs_follow_link(). Pick the value up by recognizing
> > in super.c:do_mount() the option "symlink_prefix=" before
> > giving the options to the separate filesystems.
> > 
> > [One could start a subdiscussion about that part. The mount(2)
> > system call needs to transport vfs information and per-fs information.
> > So far, the vfs information used flag bits only, but sooner or later
> > we'll want to have strings, and need a vfs_parse_mount_options().
> > Indeed, many filesystems today have uid= and gid= and umask= options
> > that might be removed from the individual filesystems and put into vfs.
> > After all, such options are also useful for (foreign) ext2 filesystems.]
> 
> _Please_, if we do anything of that kind - let's use a new syscall.
> Ideally, I'd say
> 	fs_fd = open("/fs/ext2", O_RDWR);
> 	/* error -> no such filesystem */
> 	write(fs_fd. "/dev/sda1", strlen("/dev/sda1"));
> 	/* error handling */
> 	write(fs_fd, "reserve=5", strlen(....));
> 	...
> 	dir = open("/usr/local", O_DIRECTORY);
> 	/* error handling */
> 	new_mount(dir, MNT_SET, fs_fd);	/* closes dir and fs_fd */
> 	/* error handling */
> 
> First open gives you a new channel. Preferably - wit datagram semantics (i.e.
> write() boundaries are preserved). Then you convince fs driver to give you
> fs. Then you mount it.

Looks good. Will it be possible to emulate old mount in libc in
(distant) future.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: symlink_prefix

[Edgar Toernig]

Alexander Viro wrote:
>         ...
>         dir = open("/usr/local", O_DIRECTORY);
>         /* error handling */
>         new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */

Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink, rename, mount and umount)?
Even if it were possible in the new_mount case it wouldn't have the
atomic lookup+act nature of the old mount.  And then, _I_ would
prefer a uniform interface for tree management commands - strings.

Ciao, ET.

Re: symlink_prefix

[Alexander Viro]

On Thu, 7 Jun 2001, Edgar Toernig wrote:

> Alexander Viro wrote:
> >         ...
> >         dir = open("/usr/local", O_DIRECTORY);
> >         /* error handling */
> >         new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
> 
> Do you really want to start using fds instead of strings for tree
> modifying commands (link, unlink, symlink, rename, mount and umount)?
> Even if it were possible in the new_mount case it wouldn't have the
> atomic lookup+act nature of the old mount.  And then, _I_ would
> prefer a uniform interface for tree management commands - strings.

You have exactly the same atomicity warranties. That is to say, none.
Mountpoint can be renamed between the lookup and mounting.

Moreover, even after mount(2) you can rename() parent of mountpoint. On
all Unices I've seen (well, aside of v7 which didn't have rename(2)).
So if you rely on anything of that kind - you are screwed. Portably
screwed, at that.

I would argue that mount(2) is seriously different from rename(2) and
friends, but even if your argument makes sense, it only makes sense for
"dir" argument. "device" is nothing but a filesystem-specific option.

Re: symlink_prefix

[Edgar Toernig]

Alexander Viro wrote:
> 
> On Thu, 7 Jun 2001, Edgar Toernig wrote:
> 
> > Alexander Viro wrote:
> > >         ...
> > >         dir = open("/usr/local", O_DIRECTORY);
> > >         /* error handling */
> > >         new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
> >
> > Do you really want to start using fds instead of strings for tree
> > modifying commands (link, unlink, symlink, rename, mount and umount)?
> > Even if it were possible in the new_mount case it wouldn't have the
> > atomic lookup+act nature of the old mount.  And then, _I_ would
> > prefer a uniform interface for tree management commands - strings.
> 
> You have exactly the same atomicity warranties. That is to say, none.
> Mountpoint can be renamed between the lookup and mounting.

Ok.  I thought, mounting is an atomic operation (though normally not
required).  Hmm... but looking at your last batch of VFS patches sent
to lkml you consider mount a more used call in the future ;-)  Maybe
it would be better to have some more strict rules for mount if ie each
login performs a dozen of them...

> Moreover, even after mount(2) you can rename() parent of mountpoint. On
> all Unices I've seen (well, aside of v7 which didn't have rename(2)).
> So if you rely on anything of that kind - you are screwed. Portably
> screwed, at that.

I thought more about a rename of ie "/usr/local" between the open and
the new_mount call.  I guess, an unlink("/usr/local") after the open
will let the new_mount fail.  Btw, what happens in this case of two
concurrent mounts?

	fd1=open("/foo")
	fd2=open("/foo")
	new_mount(fd1...)
	new_mount(fd2...)	// or vice versa, first fd2 then fd1

>[...] but even if your argument makes sense, it only makes sense for
> "dir" argument. "device" is nothing but a filesystem-specific option.

Sure.  I only meant the "dir" argument.

Maybe I've just an uneasy feeling about such a change because it exposes
and depends on internal implementation details of the kernel (the dcache).
On other systems it's normally not possible to associate a unique name
with a file descriptor.  Newer Linux versions may support this for
directories due to the dcache (not sure if this is really always the case).
And this calling convention for new_mount would be the first one that
makes this visible in userspace.  And it would depend on this feature.
This may limit future changes of the kernel VFS implementation (maybe
someone really adds some kind of hardlinked directories or something
else that makes it impossible to get a unique name for a dir fd).

Ciao, ET.

Re: symlink_prefix

[Hank Leininger]

On 2001-06-03, Andries.Brouwer@cwi.nl wrote:

> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
> /, /usr and /usr/spool filesystems for FOO OS. Now
>         mount /dev/a /mnt -o symlink_prefix=/mnt
>         mount /dev/b /mnt/usr -o symlink_prefix=/mnt
>         mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt

Cool.

What happens when someone creates new absolute symlinks under /mnt ?
Will/should the magic /mnt/ header be stripped from any symlink created
under such a path-translated volume?  The answer is probably 'yes', but
either one violates POLA :(

--
Hank Leininger <hlein@progressive-comp.com> 
  

Re: symlink_prefix

[Ton Hospel]

In article <200106041228.IAA08746@mailer.progressive-comp.com>,
	Hank Leininger <linux-kernel@progressive-comp.com> writes:
> On 2001-06-03, Andries.Brouwer@cwi.nl wrote:
> 
>> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
>> /, /usr and /usr/spool filesystems for FOO OS. Now
>>         mount /dev/a /mnt -o symlink_prefix=/mnt
>>         mount /dev/b /mnt/usr -o symlink_prefix=/mnt
>>         mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt
> 
> Cool.
> 
> What happens when someone creates new absolute symlinks under /mnt ?
> Will/should the magic /mnt/ header be stripped from any symlink created
> under such a path-translated volume?  The answer is probably 'yes', but
> either one violates POLA :(
> 
I think the semantics should be these that are used in the old usespace
nfsd for the "link_relative" option. That one had very intuitive semantics
and behaved sanely even if you had insane recursive machine crossmounts

Re: symlink_prefix

[Andries.Brouwer]

> We can kludge around anything. The question being, what for?
> It still leaves ncp with its ioctls ugliness.

I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.

You want to design a new interface. Maybe that is good as well,
but since it is the interface of essentially a unique program
I do not regard that as very urgent.

Andries

Re: symlink_prefix

[Andries.Brouwer]

> Current interface had grown an impressive collection of warts.
> Worse yet, you _can't_ put parsing into generic code.
> There are filesystems that have a binary object as 'data'.

Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda followed nfs.

Nevertheless, there is no problem adding vfs_parse_mount_options().
For example, one can have a flag FS_HAS_BINARY_MOUNT_DATA in
the fs_flags field of the struct file_system_type that describes
the filesystem type, and refrain from trying to parse the mount data
when this bit is set.


Andries

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> > Current interface had grown an impressive collection of warts.
> > Worse yet, you _can't_ put parsing into generic code.
> > There are filesystems that have a binary object as 'data'.
> 
> Yes, that was a very unfortunate decision, back in the good old times
> when nfs was implemented. And smb, ncp, coda followed nfs.
> 
> Nevertheless, there is no problem adding vfs_parse_mount_options().
> For example, one can have a flag FS_HAS_BINARY_MOUNT_DATA in
> the fs_flags field of the struct file_system_type that describes
> the filesystem type, and refrain from trying to parse the mount data
> when this bit is set.

We can kludge around anything. The question being, what for? It still
leaves ncp with its ioctls ugliness. It still treats device name
in a special way for no good reason - it _is_ an option, just like any
other. Hell, less generic than nosuid or read-only. It still leaves us
with cruft in flags. What for? To maintain binary compatibility with
one utility? We can leave the old interface in place and freeze it.

Re: symlink_prefix

[Albert D. Cahalan]

Alexander Viro writes:

> leaves ncp with its ioctls ugliness.

Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole box as trusted.

The /fs/ext2 stuff is one of the nastiest hacks I've seen in
a long time, and it doesn't solve the authentication problem.

GUI users might like to see a dialog box pop up whenever they
hit restricted filesystem space. (example: an authentication tool
blocked on /dev/auth-notify or getting signals with info)

Re: symlink_prefix

[Andries.Brouwer]

    From viro@math.psu.edu Sun Jun  3 13:25:31 2001

    > [One could start a subdiscussion about that part.
    > The mount(2) system call needs to transport vfs information
    > and per-fs information. So far, the vfs information used
    > flag bits only, but sooner or later we'll want to have
    > strings, and need a vfs_parse_mount_options().
    > Indeed, many filesystems today have uid= and gid= and
    > umask= options that might be removed from the individual
    > filesystems and put into vfs. After all, such options
    > are also useful for (foreign) ext2 filesystems.]

    _Please_, if we do anything of that kind - let's use a new syscall.
    Ideally, I'd say
        fs_fd = open("/fs/ext2", O_RDWR);
        /* error -> no such filesystem */
        write(fs_fd. "/dev/sda1", strlen("/dev/sda1"));
        /* error handling */
        write(fs_fd, "reserve=5", strlen(....));
        ...
        dir = open("/usr/local", O_DIRECTORY);
        /* error handling */
        new_mount(dir, MNT_SET, fs_fd);    /* closes dir and fs_fd */
        /* error handling */

    Comments?

I do not think this is an improvement. Anyway, it is orthogonal
to what I discussed.

[My version: keep interface constant, reorganize kernel source
to do certain things in one place instead of in several places.
Advantage: treatment becomes uniform and some options that make sense
for all filesystem types but are available today for some only
are generalized.
Your version: invent a new interface, be silent about what happens
inside the kernel.]

Andries

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> [My version: keep interface constant, reorganize kernel source
> to do certain things in one place instead of in several places.
> Advantage: treatment becomes uniform and some options that make sense
> for all filesystem types but are available today for some only
> are generalized.
> Your version: invent a new interface, be silent about what happens
> inside the kernel.]

Current interface had grown an impressive collection of warts. Worse
yet, you _can't_ put parsing into generic code. There are filesystems
that have a binary object as 'data'. And there are filesystems that
do post-mount authentication via ioctls on root directory.

symlink_prefix

[Andries.Brouwer]

This evening I needed to work on a filesystem of a non-Linux OS,
full of absolute symlinks. After mounting the fs on /mnt, each
symlink pointing to /foo/bar in that filesystem should be
regarded as pointing to /mnt/foo/bar.

Since doing ls -ld on every component of every pathname was
far too slow, I made a small kernel wart, where a mount option
-o symlink_prefix=/pathname would cause /pathname to be prepended
in front of every absolute symlink in the given filesystem
(when the symlink is followed). That works satisfactorily.

Remain the questions:
(i) is there already a mechanism that would achieve this?
(ii) if not, do we want something like this in the kernel?

There is already a vaguely similar (and much uglier) wart,
namely that of "altroot". It is really ugly - requires a path
set at kernel compile time. And the scope is different.
Instead of all processes and a single filesystem and symlinks only,
altroot affects a single process and all filesystems and all paths.

I do not immediately see a common generalization of these two.

Andries

Re: symlink_prefix

[Robert Love]

On 03 Jun 2001 01:54:43 +0200, Andries.Brouwer@cwi.nl wrote:
> This evening I needed to work on a filesystem of a non-Linux OS,
> full of absolute symlinks. After mounting the fs on /mnt, each
> symlink pointing to /foo/bar in that filesystem should be
> regarded as pointing to /mnt/foo/bar.
> 
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
> in front of every absolute symlink in the given filesystem
> (when the symlink is followed). That works satisfactorily.<snip>

unfortunately i cant speak for whether or not this patch is
reengineering the work of altroot (i have no experience with it) or
whether there are other similar approaches.

what i can say is that this is an excellent idea -- i have often cursed
having absolute symlinsk v. relative ones and this option would provide
a wonderful fix to that.

plus, i bet this is a rather simple and clean option.

i would like to see this in the kernel if it does not tread on any other
similar feature.

> (i) is there already a mechanism that would achieve this?
cant answer

> (ii) if not, do we want something like this in the kernel?
for sure.


-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 Andries.Brouwer@cwi.nl wrote:

> This evening I needed to work on a filesystem of a non-Linux OS,
> full of absolute symlinks. After mounting the fs on /mnt, each
> symlink pointing to /foo/bar in that filesystem should be
> regarded as pointing to /mnt/foo/bar.
> 
> Since doing ls -ld on every component of every pathname was
> far too slow, I made a small kernel wart, where a mount option
> -o symlink_prefix=/pathname would cause /pathname to be prepended
> in front of every absolute symlink in the given filesystem
> (when the symlink is followed). That works satisfactorily.
> 
> Remain the questions:
> (i) is there already a mechanism that would achieve this?
> (ii) if not, do we want something like this in the kernel?
> 
> There is already a vaguely similar (and much uglier) wart,
> namely that of "altroot". It is really ugly - requires a path
> set at kernel compile time. And the scope is different.
> Instead of all processes and a single filesystem and symlinks only,
> altroot affects a single process and all filesystems and all paths.
> 
> I do not immediately see a common generalization of these two.

altroot should be buried, not generalized. It was a mistake and
we will be better off forgetting about that nightmare instead of
trying to design something around it.

Absolute symlinks... Dunno. _If_ we want that at all, we probably
want it on per-mountpoint basis. However, that opens a door to
_really_ ugly feature requests. E.g. "if symlink starts with
/foo - replace it with /mnt/bar, but if it starts with /foo/baz -
replace with /mnt/splat instead".

I can see how to implement per-mountpoint variant. However, I'm
less than enthusiastic about the API side of that and about the
ugliness it will lead to. It smells like a wrong approach. And
no, I don't see a good one right now.

As for the API... How would you pass that option? Yet another
mount(2) argument?

Re: symlink_prefix

[Mitchell Blank Jr]

Alexander Viro wrote:
> I can see how to implement per-mountpoint variant. However, I'm
> less than enthusiastic about the API side of that and about the
> ugliness it will lead to. It smells like a wrong approach. And
> no, I don't see a good one right now.

Aren't we one day going to have stackable filesystems?  This looks like an
idea for a trivial translation filesystem to me.

-Mitch