Re: symlink_prefix
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 [EMAIL PROTECTED] In my country we have almost anarchy and I don't care. Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
In article <[EMAIL PROTECTED]>, Hank Leininger <[EMAIL PROTECTED]> writes: > On 2001-06-03, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On 2001-06-03, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
From [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
From [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On 2001-06-03, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
In article [EMAIL PROTECTED], Hank Leininger [EMAIL PROTECTED] writes: On 2001-06-03, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
From [EMAIL PROTECTED] Sun Jun 3 02:49:08 2001
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
From [EMAIL PROTECTED] Sun Jun 3 02:49:08 2001 On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On 03 Jun 2001 01:54:43 +0200, [EMAIL PROTECTED] 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. 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 [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
symlink_prefix
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
symlink_prefix
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On 03 Jun 2001 01:54:43 +0200, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
