Re: [RFC] FUSE permission modell (Was: fuse review bits)
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
IMO the '..' file descriptor should be attached to it's chroot domain.
This should avoid all chroot-escapes, even with fd-passing etc.
I wonder why nobody thought of that. Either it's too obvious or too stupid.
--
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
then used against you.
-
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: [RFC] FUSE permission modell (Was: fuse review bits)
> Likely because its a chroot vulnerability. > > It allows a process to obtain a reference to the root vfsmount that > doesn't have chroot checks performed on it. > > Consider the following pseudo example: > [...] > > if main is run within a chroot where it's "/" is on the same vfsmount as > it's "..", then the application can step out of the chroot using clone(2). > > Note: using chdir in a vfsmount outside of your namespace works, however > you won't be able to walk off that vfsmount (to its parent or children). How about fixing fchdir, so it checks whether you gone outside the tree under current->fs->rootmnt? Should be fairly easy to do. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Likely because its a chroot vulnerability. It allows a process to obtain a reference to the root vfsmount that doesn't have chroot checks performed on it. Consider the following pseudo example: [...] if main is run within a chroot where it's / is on the same vfsmount as it's .., then the application can step out of the chroot using clone(2). Note: using chdir in a vfsmount outside of your namespace works, however you won't be able to walk off that vfsmount (to its parent or children). How about fixing fchdir, so it checks whether you gone outside the tree under current-fs-rootmnt? Should be fairly easy to do. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Mike Waychison [EMAIL PROTECTED] wrote: Consider the following pseudo example: main(): chdir(/); fd = open(., O_RDONLY); clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL); cloned_func: fchdir(fd); chdir(..); if main is run within a chroot where it's / is on the same vfsmount as it's .., then the application can step out of the chroot using clone(2). Note: using chdir in a vfsmount outside of your namespace works, however you won't be able to walk off that vfsmount (to its parent or children). IMO the '..' file descriptor should be attached to it's chroot domain. This should avoid all chroot-escapes, even with fd-passing etc. I wonder why nobody thought of that. Either it's too obvious or too stupid. -- Funny quotes: 7. You have the right to remain silent. Anything you say will be misquoted, then used against you. - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen wrote:
> Somewhat related question for Viro/the group:
>
> Why is CLONE_NEWNS considered a priveledged operation? Would placing
> limits on the number of private namespaces a user can own solve any
> resource concerns or is there something more nefarious I'm missing?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Likely because its a chroot vulnerability.
It allows a process to obtain a reference to the root vfsmount that
doesn't have chroot checks performed on it.
Consider the following pseudo example:
main():
chdir("/");
fd = open(".", O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir("..");
if main is run within a chroot where it's "/" is on the same vfsmount as
it's "..", then the application can step out of the chroot using clone(2).
Note: using chdir in a vfsmount outside of your namespace works, however
you won't be able to walk off that vfsmount (to its parent or children).
Mike Waychison
-
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: [RFC] FUSE permission modell (Was: fuse review bits)
Somewhat related question for Viro/the group: Why is CLONE_NEWNS considered a priveledged operation? Would placing limits on the number of private namespaces a user can own solve any resource concerns or is there something more nefarious I'm missing? - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote: > On 4/19/05, Bodo Eggert <[EMAIL PROTECTED]> wrote: > > Allowing user mounts with no* should be allways ok (no config needed > > besides the ulimit), and mounting specified files to defined locations > > is allready supported by fstab. > > > > Do folks think that the limits should be per-user or per-process for > user-mounts, what about separate limits for # of private namespaces > and # of mounts? Per-user. > The fstab support doesn't seem to provide enough flexibility for > certain situations, say I want to support mounting any remote file > system, as long as its in the user's private hierarchy? [...] The dir is owned by the user, therefore it's allowed with no*. -- Top 100 things you don't want the sysadmin to say: 11. Can you get VMS for this Sparc thingy? - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/19/05, Bodo Eggert <[EMAIL PROTECTED]> wrote: > > > > Well, that would kinda be the intent behind the permissions file -- > > it can specify what restricted set of images/devices/whatever the user > > can mount, I suppose the sensible thing would be to always enforce > > nosuid and nsgid, but I'd rather keep these as the default version of > > options (allowing admins to shoot themselves in the foot perhaps, but > > in the single-user workstation case, is seems like there's less reason > > to be so paranoid). > > I think you shouldn't help the admins by creating shoes with target marks. > Fair enough. Since I don't really have any cases I can think of that require this sort of behavior, I'll back off on allowing user mounts with suid or sgid enabled. > > Allowing user mounts with no* should be allways ok (no config needed > besides the ulimit), and mounting specified files to defined locations > is allready supported by fstab. > Do folks think that the limits should be per-user or per-process for user-mounts, what about separate limits for # of private namespaces and # of mounts? The fstab support doesn't seem to provide enough flexibility for certain situations, say I want to support mounting any remote file system, as long as its in the user's private hierarchy? What if I want user's to be able to mount FUSE, v9fs, etc. user-space file systems, but only in a private namespace and only in their private hierarchy? Or are these situations which you think should "always be okay" as long as nosuid and nogid (and newns?) are implicit? -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > I think you shouldn't help the admins by creating shoes with target marks. > > Allowing user mounts with no* should be allways ok (no config needed > besides the ulimit), and mounting specified files to defined locations > is allready supported by fstab. I tend to agree. It should be obvious which sort of mounts are safe and which are not. The exceptions can go into fstab. In a private namespace environment bind mounts (nodev,nosuid) should be OK. Network filesystems (with limitations to the ports used) are also. Disk filesystems are usually not safe to mount for users, because they are not tested and verified against untrusted source. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote: > On 4/17/05, Bodo Eggert <[EMAIL PROTECTED]> > > > I was thinking about this a while back and thought having a user-mount > > > permissions file might be the right way to address lots of these > > > issues. Essentially it would contain information about what > > > users/groups were allowed to mount what sources to what destinations > > > and with what mandatory options. > > > > Users being able to mount random fs containing suid or device nodes > > are root whenever they want to. If you want to mount with dev or suid, > > use sudo and restrict the mount to a limited set of images/devices/whatever. > > Well, that would kinda be the intent behind the permissions file -- > it can specify what restricted set of images/devices/whatever the user > can mount, I suppose the sensible thing would be to always enforce > nosuid and nsgid, but I'd rather keep these as the default version of > options (allowing admins to shoot themselves in the foot perhaps, but > in the single-user workstation case, is seems like there's less reason > to be so paranoid). I think you shouldn't help the admins by creating shoes with target marks. Allowing user mounts with no* should be allways ok (no config needed besides the ulimit), and mounting specified files to defined locations is allready supported by fstab. -- Top 100 things you don't want the sysadmin to say: 6. We prefer not to change the root password, it's an nice easy one - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/17/05, Bodo Eggert <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > > > I was thinking about this a while back and thought having a user-mount > > permissions file might be the right way to address lots of these > > issues. Essentially it would contain information about what > > users/groups were allowed to mount what sources to what destinations > > and with what mandatory options. > > Users being able to mount random fs containing suid or device nodes > are root whenever they want to. If you want to mount with dev or suid, > use sudo and restrict the mount to a limited set of images/devices/whatever. > Well, that would kinda be the intent behind the permissions file -- it can specify what restricted set of images/devices/whatever the user can mount, I suppose the sensible thing would be to always enforce nosuid and nsgid, but I'd rather keep these as the default version of options (allowing admins to shoot themselves in the foot perhaps, but in the single-user workstation case, is seems like there's less reason to be so paranoid). -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/17/05, Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. Well, that would kinda be the intent behind the permissions file -- it can specify what restricted set of images/devices/whatever the user can mount, I suppose the sensible thing would be to always enforce nosuid and nsgid, but I'd rather keep these as the default version of options (allowing admins to shoot themselves in the foot perhaps, but in the single-user workstation case, is seems like there's less reason to be so paranoid). -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote: On 4/17/05, Bodo Eggert [EMAIL PROTECTED] I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. Well, that would kinda be the intent behind the permissions file -- it can specify what restricted set of images/devices/whatever the user can mount, I suppose the sensible thing would be to always enforce nosuid and nsgid, but I'd rather keep these as the default version of options (allowing admins to shoot themselves in the foot perhaps, but in the single-user workstation case, is seems like there's less reason to be so paranoid). I think you shouldn't help the admins by creating shoes with target marks. Allowing user mounts with no* should be allways ok (no config needed besides the ulimit), and mounting specified files to defined locations is allready supported by fstab. -- Top 100 things you don't want the sysadmin to say: 6. We prefer not to change the root password, it's an nice easy one - 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: [RFC] FUSE permission modell (Was: fuse review bits)
I think you shouldn't help the admins by creating shoes with target marks. Allowing user mounts with no* should be allways ok (no config needed besides the ulimit), and mounting specified files to defined locations is allready supported by fstab. I tend to agree. It should be obvious which sort of mounts are safe and which are not. The exceptions can go into fstab. In a private namespace environment bind mounts (nodev,nosuid) should be OK. Network filesystems (with limitations to the ports used) are also. Disk filesystems are usually not safe to mount for users, because they are not tested and verified against untrusted source. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote: Well, that would kinda be the intent behind the permissions file -- it can specify what restricted set of images/devices/whatever the user can mount, I suppose the sensible thing would be to always enforce nosuid and nsgid, but I'd rather keep these as the default version of options (allowing admins to shoot themselves in the foot perhaps, but in the single-user workstation case, is seems like there's less reason to be so paranoid). I think you shouldn't help the admins by creating shoes with target marks. Fair enough. Since I don't really have any cases I can think of that require this sort of behavior, I'll back off on allowing user mounts with suid or sgid enabled. Allowing user mounts with no* should be allways ok (no config needed besides the ulimit), and mounting specified files to defined locations is allready supported by fstab. Do folks think that the limits should be per-user or per-process for user-mounts, what about separate limits for # of private namespaces and # of mounts? The fstab support doesn't seem to provide enough flexibility for certain situations, say I want to support mounting any remote file system, as long as its in the user's private hierarchy? What if I want user's to be able to mount FUSE, v9fs, etc. user-space file systems, but only in a private namespace and only in their private hierarchy? Or are these situations which you think should always be okay as long as nosuid and nogid (and newns?) are implicit? -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote: On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote: Allowing user mounts with no* should be allways ok (no config needed besides the ulimit), and mounting specified files to defined locations is allready supported by fstab. Do folks think that the limits should be per-user or per-process for user-mounts, what about separate limits for # of private namespaces and # of mounts? Per-user. The fstab support doesn't seem to provide enough flexibility for certain situations, say I want to support mounting any remote file system, as long as its in the user's private hierarchy? [...] The dir is owned by the user, therefore it's allowed with no*. -- Top 100 things you don't want the sysadmin to say: 11. Can you get VMS for this Sparc thingy? - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Somewhat related question for Viro/the group: Why is CLONE_NEWNS considered a priveledged operation? Would placing limits on the number of private namespaces a user can own solve any resource concerns or is there something more nefarious I'm missing? - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen wrote: Somewhat related question for Viro/the group: Why is CLONE_NEWNS considered a priveledged operation? Would placing limits on the number of private namespaces a user can own solve any resource concerns or is there something more nefarious I'm missing? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Likely because its a chroot vulnerability. It allows a process to obtain a reference to the root vfsmount that doesn't have chroot checks performed on it. Consider the following pseudo example: main(): chdir(/); fd = open(., O_RDONLY); clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL); cloned_func: fchdir(fd); chdir(..); if main is run within a chroot where it's / is on the same vfsmount as it's .., then the application can step out of the chroot using clone(2). Note: using chdir in a vfsmount outside of your namespace works, however you won't be able to walk off that vfsmount (to its parent or children). Mike Waychison - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) >> >> 2) Use nosuid,nodev mount options [...] > Do these solve all the security concerns with unprivileged mounts, or > are there other barriers/concerns? Should there be ulimit (or rlimit) > style restrictions on how many mounts/binds a user is allowed to have > to prevent users from abusing mount privs? Definitively. Mountpoints use kernel space, the users could DoS the machine. The per-Machine-limit isn't fine-grained enough, since the users may DoS each other. You'll have to avoid users capturing system daemons in D state or in slowed-down artificial directory-forests, too. I think namespaces will do most the trick. > I was thinking about this a while back and thought having a user-mount > permissions file might be the right way to address lots of these > issues. Essentially it would contain information about what > users/groups were allowed to mount what sources to what destinations > and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. -- Anger, fear, aggression. The Dark Side of the Force are they. Once you start down the Dark Path, forever will it dominate your destiny. -- Jedi Master Yoda - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/17/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > > > 1) Only allow mount over a directory for which the user has write > > > access (and is not sticky) > > > > > > 2) Use nosuid,nodev mount options > > > > > > [ parts deleted ] > > > > Do these solve all the security concerns with unprivileged mounts, or > > are there other barriers/concerns? Should there be ulimit (or rlimit) > > style restrictions on how many mounts/binds a user is allowed to have > > to prevent users from abusing mount privs? > > Currently there is a (configurable) global limit for all non-root FUSE > mounts. An additional per-user limit would be nice, but from the > security standpoint it doesn't matter. > > > I was thinking about this a while back and thought having a user-mount > > permissions file might be the right way to address lots of these > > issues. Essentially it would contain information about what > > users/groups were allowed to mount what sources to what destinations > > and with what mandatory options. > > I haven't yet seen the need for such a great flexibility. Debian > installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse", These are both well and good, but I was looking for a more global system (for things other than FUSE). > > > Is this unnecessary? Is this not enough? > > Maybe it is necessary, but why bother until somebody actually wants > it? I'm a great believer of the "lazy" development philosophy ;) > Yeah, I guess I'm motivated in that I want to use normal mount to handle v9fs user file systems, local private mounts, and local private resource shares. I'd also like normal users to be able to take better advantage of -o bind. I think its kinda silly that we have special purpose mounts for cifs, samba, fuse, v9fs, etc -- but I suppose that's more of a user-space util-linux dilemma than a kernel dilemma. -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > > 1) Only allow mount over a directory for which the user has write > > access (and is not sticky) > > > > 2) Use nosuid,nodev mount options > > > > [ parts deleted ] > > Do these solve all the security concerns with unprivileged mounts, or > are there other barriers/concerns? Should there be ulimit (or rlimit) > style restrictions on how many mounts/binds a user is allowed to have > to prevent users from abusing mount privs? Currently there is a (configurable) global limit for all non-root FUSE mounts. An additional per-user limit would be nice, but from the security standpoint it doesn't matter. > I was thinking about this a while back and thought having a user-mount > permissions file might be the right way to address lots of these > issues. Essentially it would contain information about what > users/groups were allowed to mount what sources to what destinations > and with what mandatory options. I haven't yet seen the need for such a great flexibility. Debian installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse", so only users in the "fuse" group are allowed to use it. This is sane for a new technology, but I expect these limitations to be removed once it establishes itsef as a secure solution. > You can get the start of this with the user/users/etc. stuff in > /etc/fstab, but I was envisioning something a bit more dynamic with > regular expression based rules for sources and destinations. So, > something like: [snip] > Is this unnecessary? Is this not enough? Maybe it is necessary, but why bother until somebody actually wants it? I'm a great believer of the "lazy" development philosophy ;) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen wrote: > I'd like to second that I think private-namespaces are the right way > to solve this sort of problem. It also helps not cluttering the > global namespace with user-local mounts > > > > > Shared subtrees and more support in userspace tools is needed before > > private namespaces can become really useful. > > > > I'd like to talk about this a bit more and start driving to a solution > here. I've been looking at the namespace code quite a bit and was > just about to dive in and start checking into adding/fixing certain > aspects such as stackable namespaces, optional inheritence (changes in > a parent namespace are reflected in the child but not vice-versa), > etc. > > One aspect I was thinking about here was a mount flag that would give > you a new private namespace (if you didn't already have one) for the > mount (and I guess that would impact any subsequent mounts from the > user in that shell). Another option would be a 'newns' style > system-call, but I'm generally against adding new system calls. > > Shared subtrees are a tricky one. I know how we would handle it in > V9FS, but not sure how well that would translate to others > (essentially we'd re-export the subtree so other user's could mount it > individually -- but that's a very Plan 9 solution and may not be what > more UNIX-minded folks would want -- we also need to improve our own > server infrastructure to more efficiently support such a re-export). > > So, to sum up I think private namespaces is the right solution, and > I'd rather put effort into making it more useful than work-around the > fact that its not practical right now. Have a chat with Al Viro, who has already done some work on shared mounts and subtrees I think. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > 1) Only allow mount over a directory for which the user has write > access (and is not sticky) > > 2) Use nosuid,nodev mount options > > [ parts deleted ] Do these solve all the security concerns with unprivileged mounts, or are there other barriers/concerns? Should there be ulimit (or rlimit) style restrictions on how many mounts/binds a user is allowed to have to prevent users from abusing mount privs? I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. You can get the start of this with the user/users/etc. stuff in /etc/fstab, but I was envisioning something a bit more dynamic with regular expression based rules for sources and destinations. So, something like: # /etc/usermounts: user mount permissions # # allow users to mount any file system under their home directory * $HOME * nosuid, nosgid # allow users to bind over /usr/bin as long as its only in their private namespace * /usr/bin bindnewns # allow users to loopback mount distributed file systems to /mnt 127.0.0.1 /mnt * nosuid, nosgid # allow users to mount files over any directory they have right access to * (perm=0222) * nosuid, nosgid Is this unnecessary? Is this not enough? -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/12/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > I think that would be _much_ nicer implemented as a mount which is > > invisible to other users, rather than one which causes the admin's > > scripts to spew error messages. >> > > Is the namespace mechanism at all suitable for that? > > It is certainly the right tool for this. However currently private > namespaces are quite limited. The only sane usage I can think of is > that before mounting the user starts a shell with CLONE_NS, and does > the mount in this. However all the other programs he already has > running (editor, browser, desktop environment) won't be able to access > the mount. > I'd like to second that I think private-namespaces are the right way to solve this sort of problem. It also helps not cluttering the global namespace with user-local mounts > > Shared subtrees and more support in userspace tools is needed before > private namespaces can become really useful. > I'd like to talk about this a bit more and start driving to a solution here. I've been looking at the namespace code quite a bit and was just about to dive in and start checking into adding/fixing certain aspects such as stackable namespaces, optional inheritence (changes in a parent namespace are reflected in the child but not vice-versa), etc. One aspect I was thinking about here was a mount flag that would give you a new private namespace (if you didn't already have one) for the mount (and I guess that would impact any subsequent mounts from the user in that shell). Another option would be a 'newns' style system-call, but I'm generally against adding new system calls. Shared subtrees are a tricky one. I know how we would handle it in V9FS, but not sure how well that would translate to others (essentially we'd re-export the subtree so other user's could mount it individually -- but that's a very Plan 9 solution and may not be what more UNIX-minded folks would want -- we also need to improve our own server infrastructure to more efficiently support such a re-export). So, to sum up I think private namespaces is the right solution, and I'd rather put effort into making it more useful than work-around the fact that its not practical right now. -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/12/05, Miklos Szeredi [EMAIL PROTECTED] wrote: I think that would be _much_ nicer implemented as a mount which is invisible to other users, rather than one which causes the admin's scripts to spew error messages. Is the namespace mechanism at all suitable for that? It is certainly the right tool for this. However currently private namespaces are quite limited. The only sane usage I can think of is that before mounting the user starts a shell with CLONE_NS, and does the mount in this. However all the other programs he already has running (editor, browser, desktop environment) won't be able to access the mount. I'd like to second that I think private-namespaces are the right way to solve this sort of problem. It also helps not cluttering the global namespace with user-local mounts Shared subtrees and more support in userspace tools is needed before private namespaces can become really useful. I'd like to talk about this a bit more and start driving to a solution here. I've been looking at the namespace code quite a bit and was just about to dive in and start checking into adding/fixing certain aspects such as stackable namespaces, optional inheritence (changes in a parent namespace are reflected in the child but not vice-versa), etc. One aspect I was thinking about here was a mount flag that would give you a new private namespace (if you didn't already have one) for the mount (and I guess that would impact any subsequent mounts from the user in that shell). Another option would be a 'newns' style system-call, but I'm generally against adding new system calls. Shared subtrees are a tricky one. I know how we would handle it in V9FS, but not sure how well that would translate to others (essentially we'd re-export the subtree so other user's could mount it individually -- but that's a very Plan 9 solution and may not be what more UNIX-minded folks would want -- we also need to improve our own server infrastructure to more efficiently support such a re-export). So, to sum up I think private namespaces is the right solution, and I'd rather put effort into making it more useful than work-around the fact that its not practical right now. -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote: 1) Only allow mount over a directory for which the user has write access (and is not sticky) 2) Use nosuid,nodev mount options [ parts deleted ] Do these solve all the security concerns with unprivileged mounts, or are there other barriers/concerns? Should there be ulimit (or rlimit) style restrictions on how many mounts/binds a user is allowed to have to prevent users from abusing mount privs? I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. You can get the start of this with the user/users/etc. stuff in /etc/fstab, but I was envisioning something a bit more dynamic with regular expression based rules for sources and destinations. So, something like: # /etc/usermounts: user mount permissions # fsmount point type opts # allow users to mount any file system under their home directory * $HOME * nosuid, nosgid # allow users to bind over /usr/bin as long as its only in their private namespace * /usr/bin bindnewns # allow users to loopback mount distributed file systems to /mnt 127.0.0.1 /mnt * nosuid, nosgid # allow users to mount files over any directory they have right access to * (perm=0222) * nosuid, nosgid Is this unnecessary? Is this not enough? -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen wrote: I'd like to second that I think private-namespaces are the right way to solve this sort of problem. It also helps not cluttering the global namespace with user-local mounts Shared subtrees and more support in userspace tools is needed before private namespaces can become really useful. I'd like to talk about this a bit more and start driving to a solution here. I've been looking at the namespace code quite a bit and was just about to dive in and start checking into adding/fixing certain aspects such as stackable namespaces, optional inheritence (changes in a parent namespace are reflected in the child but not vice-versa), etc. One aspect I was thinking about here was a mount flag that would give you a new private namespace (if you didn't already have one) for the mount (and I guess that would impact any subsequent mounts from the user in that shell). Another option would be a 'newns' style system-call, but I'm generally against adding new system calls. Shared subtrees are a tricky one. I know how we would handle it in V9FS, but not sure how well that would translate to others (essentially we'd re-export the subtree so other user's could mount it individually -- but that's a very Plan 9 solution and may not be what more UNIX-minded folks would want -- we also need to improve our own server infrastructure to more efficiently support such a re-export). So, to sum up I think private namespaces is the right solution, and I'd rather put effort into making it more useful than work-around the fact that its not practical right now. Have a chat with Al Viro, who has already done some work on shared mounts and subtrees I think. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
1) Only allow mount over a directory for which the user has write access (and is not sticky) 2) Use nosuid,nodev mount options [ parts deleted ] Do these solve all the security concerns with unprivileged mounts, or are there other barriers/concerns? Should there be ulimit (or rlimit) style restrictions on how many mounts/binds a user is allowed to have to prevent users from abusing mount privs? Currently there is a (configurable) global limit for all non-root FUSE mounts. An additional per-user limit would be nice, but from the security standpoint it doesn't matter. I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. I haven't yet seen the need for such a great flexibility. Debian installs fusermount (the FUSE mount utility) -rwsr-x--- root fuse, so only users in the fuse group are allowed to use it. This is sane for a new technology, but I expect these limitations to be removed once it establishes itsef as a secure solution. You can get the start of this with the user/users/etc. stuff in /etc/fstab, but I was envisioning something a bit more dynamic with regular expression based rules for sources and destinations. So, something like: [snip] Is this unnecessary? Is this not enough? Maybe it is necessary, but why bother until somebody actually wants it? I'm a great believer of the lazy development philosophy ;) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On 4/17/05, Miklos Szeredi [EMAIL PROTECTED] wrote: 1) Only allow mount over a directory for which the user has write access (and is not sticky) 2) Use nosuid,nodev mount options [ parts deleted ] Do these solve all the security concerns with unprivileged mounts, or are there other barriers/concerns? Should there be ulimit (or rlimit) style restrictions on how many mounts/binds a user is allowed to have to prevent users from abusing mount privs? Currently there is a (configurable) global limit for all non-root FUSE mounts. An additional per-user limit would be nice, but from the security standpoint it doesn't matter. I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. I haven't yet seen the need for such a great flexibility. Debian installs fusermount (the FUSE mount utility) -rwsr-x--- root fuse, These are both well and good, but I was looking for a more global system (for things other than FUSE). Is this unnecessary? Is this not enough? Maybe it is necessary, but why bother until somebody actually wants it? I'm a great believer of the lazy development philosophy ;) Yeah, I guess I'm motivated in that I want to use normal mount to handle v9fs user file systems, local private mounts, and local private resource shares. I'd also like normal users to be able to take better advantage of -o bind. I think its kinda silly that we have special purpose mounts for cifs, samba, fuse, v9fs, etc -- but I suppose that's more of a user-space util-linux dilemma than a kernel dilemma. -eric - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen [EMAIL PROTECTED] wrote: On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote: 1) Only allow mount over a directory for which the user has write access (and is not sticky) 2) Use nosuid,nodev mount options [...] Do these solve all the security concerns with unprivileged mounts, or are there other barriers/concerns? Should there be ulimit (or rlimit) style restrictions on how many mounts/binds a user is allowed to have to prevent users from abusing mount privs? Definitively. Mountpoints use kernel space, the users could DoS the machine. The per-Machine-limit isn't fine-grained enough, since the users may DoS each other. You'll have to avoid users capturing system daemons in D state or in slowed-down artificial directory-forests, too. I think namespaces will do most the trick. I was thinking about this a while back and thought having a user-mount permissions file might be the right way to address lots of these issues. Essentially it would contain information about what users/groups were allowed to mount what sources to what destinations and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. -- Anger, fear, aggression. The Dark Side of the Force are they. Once you start down the Dark Path, forever will it dominate your destiny. -- Jedi Master Yoda - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > Yet, the results from stat() don't distinguish the number spaces, > > > and "ls" doesn't map the numbers to names properly in the wrong > > > space. > > > > Well you can use "ls -n". It's up to the tools to present the > > information you want in the way you want it. If a tool can't do that, > > tough, but you are not worse off than if the information is not > > available _at_all_. > > Well, how do you currently provide access to the information that's > not presentable through stat()? Obviously I don't. However that's hardly an argument for providing even less information. And stat() btw pretty much covers what information there is to present for network filesystems and archives, since there _is_ a real filesystem where the information originated from (though sometimes it's not a UNIX type of filesystem, in which case there has to be some mapping of the info). Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > Yet, the results from stat() don't distinguish the number spaces, > > and "ls" doesn't map the numbers to names properly in the wrong > > space. > > Well you can use "ls -n". It's up to the tools to present the > information you want in the way you want it. If a tool can't do that, > tough, but you are not worse off than if the information is not > available _at_all_. Well, how do you currently provide access to the information that's not presentable through stat()? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > I have a little project to imlement a "userloop" filesystem, which > > works just like "mount -o loop", but you don't need root privs. This > > is really simple to do with FUSE and UML. > > That would be a nice way to implement those rarely used old > filesystems that aren't really needed in the kernel source tree any > more, but which it would be nice to have access to as legacy > filesystem formats. > > In other words, migrating old legacy filesystems out of the kernel > tree, into FUSE. Not much migration would be needed other than deleting from the current kernel. As long as the lagacy filesystem exists in a kernel that has UML support it should just work. > > I don't think that it's far feched, that in certain situations the > > user _does_ have the right (and usefulness) to do otherwise privileged > > filesystem operations. > > It's really a matter of philosophy, as to whether the results of > stat() are just handy information for the user, or are always defined > to mean what you can/can't do with a file. Yes, this is the very heart of the conflict between my and your (Christoph's, etc) view. I argue for more flexibilty, i.e. less policy in kernel, which is a good thing generally. As long as it's secure, what is the problem with it? If users are confused, then they will chose the strict mode. If somebody would like to see more information in the filesystem, they use the relaxed mode. The key here is security IMO. So if you find a security problem with the relaxed mode (together with "hiding") then I bow my head. Otherwise who cares if it confuses applications (haven't met any) or users. It doensn't matter. If it confuses anything or anyone, the filesystem writer can fix it. > Local-ssh-into-UML makes more sense for this in some ways, because the > uids/gids inside your tgz files or foreign loop filesystems are not > related to the space of uids/gids of the host system. Ssh into UML is awkward, because you don't necessary have all the tools installed, have networking, etc. And in UML the uid/gid won't make any more sense either. > Yet, the results from stat() don't distinguish the number spaces, > and "ls" doesn't map the numbers to names properly in the wrong > space. Well you can use "ls -n". It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > I have a little project to imlement a "userloop" filesystem, which > works just like "mount -o loop", but you don't need root privs. This > is really simple to do with FUSE and UML. That would be a nice way to implement those rarely used old filesystems that aren't really needed in the kernel source tree any more, but which it would be nice to have access to as legacy filesystem formats. In other words, migrating old legacy filesystems out of the kernel tree, into FUSE. > I don't think that it's far feched, that in certain situations the > user _does_ have the right (and usefulness) to do otherwise privileged > filesystem operations. It's really a matter of philosophy, as to whether the results of stat() are just handy information for the user, or are always defined to mean what you can/can't do with a file. Local-ssh-into-UML makes more sense for this in some ways, because the uids/gids inside your tgz files or foreign loop filesystems are not related to the space of uids/gids of the host system. Yet, the results from stat() don't distinguish the number spaces, and "ls" doesn't map the numbers to names properly in the wrong space. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > Look up the rather large linux-kernel & linux-fsdevel thread "silent > > semantic changes with reiser4" and it's followup threads, from last > > year. > > Wow, it's 700+ messages. I got through the first 40, and already feel > dizzy :) It's easier if you skip the ones by Hans and their immediate followups :) (Nothing personal, it's that Hans is mostly justifying reiser4's behaviour, and the posts you really need to read aren't about reiser4). > > It's already been tried. You will also find sensible ideas on what > > semantics it should have to do it properly. > > OK, I understand the "slash -> directory, no-slash -> regular file" > semantics. > > How do you envision implementing this for "mount directory over file"? Somewhere deep in that thread is a discussion between Al Viro and Linus on it. > A new mount flag indicating that it's only to be followed down if > there's a slash after the mountpoint? The new flag would indicate more than that: These mounts should be detachable in the sense that deleting the file is possible, and perhaps renamable/linkable too. That's the stuff Al Viro discusses in some detail in the big thread. Ideally we'd like automounting, a bit like the Hurd's translators. Attached to files (using an xattr or something, and executed with the uid/gid of the file owner), and also per-user "pattern->action" options for matching files with a certain type (e.g. tgz/zip/deb/rpm/xml). But that can be added much later, as it's an orthogonal feature. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> Look up the rather large linux-kernel & linux-fsdevel thread "silent > semantic changes with reiser4" and it's followup threads, from last > year. Wow, it's 700+ messages. I got through the first 40, and already feel dizzy :) > It's already been tried. You will also find sensible ideas on what > semantics it should have to do it properly. OK, I understand the "slash -> directory, no-slash -> regular file" semantics. How do you envision implementing this for "mount directory over file"? A new mount flag indicating that it's only to be followed down if there's a slash after the mountpoint? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > > Aren't there some assumptions in VFS that currently make this > > > impossible? > > > > I believe it's OK with VFS, but applications would be confused to death. > > Well, there really is one issue -- dentries have exactly one parent, so > > what do you do when opening a file with hardlinks as a directory? (In > > fact IIRC that is what lead to all the funny talk about mountpoints, > > since they don't have this limitation) > > OK, that makes sense. > > It would be quite interesting to see how applications react. Maybe > I'll hack something up :) Look up the rather large linux-kernel & linux-fsdevel thread "silent semantic changes with reiser4" and it's followup threads, from last year. It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > A nice implemention of it in FUSE could push it along a bit :) > > > > Aren't there some assumptions in VFS that currently make this > > impossible? > > I believe it's OK with VFS, but applications would be confused to death. > Well, there really is one issue -- dentries have exactly one parent, so > what do you do when opening a file with hardlinks as a directory? (In > fact IIRC that is what lead to all the funny talk about mountpoints, > since they don't have this limitation) Hardlinks aren't a problem when entering a file as if it's a directory, provided the directory does not contain any hard links to a parent in the hierarchy. In other words, as long as it's a directed acyclic graph. This is trivially always true for virtual directories such as entering an archive file. And detachable/movable mountpoints are a nice and sensible way to implement it. Some work has actually been done on this. Experiments with the reiserfs file-as-directory extension showed that applications are generally ok with it. It looks like a file, but you can cd into it or follow a path lookup into it. Linus had some good ideas on the exact semantics to implement when doing path lookup on these objects. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > Aren't there some assumptions in VFS that currently make this > > impossible? > > I believe it's OK with VFS, but applications would be confused to death. > Well, there really is one issue -- dentries have exactly one parent, so > what do you do when opening a file with hardlinks as a directory? (In > fact IIRC that is what lead to all the funny talk about mountpoints, > since they don't have this limitation) OK, that makes sense. It would be quite interesting to see how applications react. Maybe I'll hack something up :) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote: > > > There are uses for both. For example today I was updating the tar ball > > > which is used to create the var file system for a new chroot. I > > > certainly > > > want to see corretly setup owner/permissions when I look into that tar > > > ball using a FUSE fs... > > > > If I'm updating a var filesystem for a new chroot, I'd need the > > ability to chmod and chown things in that filesystem. Does that work > > as an ordinary user? > > Yes, within UML for example. That's a bad example. UML does in fact *NOT* invoke host kernel's chmod, because it has all the filesystem in a file. But the answer is yes anyway. It's up to the filesystem to check whether it is allowed. FUSE does not block it and if the actual userland driver does not protest either, it is possible. >[...] --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote: > > There was a thread a few months ago where file-as-directory was > > discussed extensively, after Namesys implemented it. That's where the > > conversation on detachable mount points originated AFAIR. It will > > probably happen at some point. > > > > A nice implemention of it in FUSE could push it along a bit :) > > Aren't there some assumptions in VFS that currently make this > impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > There are uses for both. For example today I was updating the tar ball > > which is used to create the var file system for a new chroot. I certainly > > want to see corretly setup owner/permissions when I look into that tar > > ball using a FUSE fs... > > If I'm updating a var filesystem for a new chroot, I'd need the > ability to chmod and chown things in that filesystem. Does that work > as an ordinary user? Yes, within UML for example. I have a little project to imlement a "userloop" filesystem, which works just like "mount -o loop", but you don't need root privs. This is really simple to do with FUSE and UML. I don't think that it's far feched, that in certain situations the user _does_ have the right (and usefulness) to do otherwise privileged filesystem operations. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
There are uses for both. For example today I was updating the tar ball which is used to create the var file system for a new chroot. I certainly want to see corretly setup owner/permissions when I look into that tar ball using a FUSE fs... If I'm updating a var filesystem for a new chroot, I'd need the ability to chmod and chown things in that filesystem. Does that work as an ordinary user? Yes, within UML for example. I have a little project to imlement a userloop filesystem, which works just like mount -o loop, but you don't need root privs. This is really simple to do with FUSE and UML. I don't think that it's far feched, that in certain situations the user _does_ have the right (and usefulness) to do otherwise privileged filesystem operations. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote: There was a thread a few months ago where file-as-directory was discussed extensively, after Namesys implemented it. That's where the conversation on detachable mount points originated AFAIR. It will probably happen at some point. A nice implemention of it in FUSE could push it along a bit :) Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote: There are uses for both. For example today I was updating the tar ball which is used to create the var file system for a new chroot. I certainly want to see corretly setup owner/permissions when I look into that tar ball using a FUSE fs... If I'm updating a var filesystem for a new chroot, I'd need the ability to chmod and chown things in that filesystem. Does that work as an ordinary user? Yes, within UML for example. That's a bad example. UML does in fact *NOT* invoke host kernel's chmod, because it has all the filesystem in a file. But the answer is yes anyway. It's up to the filesystem to check whether it is allowed. FUSE does not block it and if the actual userland driver does not protest either, it is possible. [...] --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) OK, that makes sense. It would be quite interesting to see how applications react. Maybe I'll hack something up :) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
A nice implemention of it in FUSE could push it along a bit :) Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) Hardlinks aren't a problem when entering a file as if it's a directory, provided the directory does not contain any hard links to a parent in the hierarchy. In other words, as long as it's a directed acyclic graph. This is trivially always true for virtual directories such as entering an archive file. And detachable/movable mountpoints are a nice and sensible way to implement it. Some work has actually been done on this. Experiments with the reiserfs file-as-directory extension showed that applications are generally ok with it. It looks like a file, but you can cd into it or follow a path lookup into it. Linus had some good ideas on the exact semantics to implement when doing path lookup on these objects. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: Aren't there some assumptions in VFS that currently make this impossible? I believe it's OK with VFS, but applications would be confused to death. Well, there really is one issue -- dentries have exactly one parent, so what do you do when opening a file with hardlinks as a directory? (In fact IIRC that is what lead to all the funny talk about mountpoints, since they don't have this limitation) OK, that makes sense. It would be quite interesting to see how applications react. Maybe I'll hack something up :) Look up the rather large linux-kernel linux-fsdevel thread silent semantic changes with reiser4 and it's followup threads, from last year. It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Look up the rather large linux-kernel linux-fsdevel thread silent semantic changes with reiser4 and it's followup threads, from last year. Wow, it's 700+ messages. I got through the first 40, and already feel dizzy :) It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. OK, I understand the slash - directory, no-slash - regular file semantics. How do you envision implementing this for mount directory over file? A new mount flag indicating that it's only to be followed down if there's a slash after the mountpoint? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: Look up the rather large linux-kernel linux-fsdevel thread silent semantic changes with reiser4 and it's followup threads, from last year. Wow, it's 700+ messages. I got through the first 40, and already feel dizzy :) It's easier if you skip the ones by Hans and their immediate followups :) (Nothing personal, it's that Hans is mostly justifying reiser4's behaviour, and the posts you really need to read aren't about reiser4). It's already been tried. You will also find sensible ideas on what semantics it should have to do it properly. OK, I understand the slash - directory, no-slash - regular file semantics. How do you envision implementing this for mount directory over file? Somewhere deep in that thread is a discussion between Al Viro and Linus on it. A new mount flag indicating that it's only to be followed down if there's a slash after the mountpoint? The new flag would indicate more than that: These mounts should be detachable in the sense that deleting the file is possible, and perhaps renamable/linkable too. That's the stuff Al Viro discusses in some detail in the big thread. Ideally we'd like automounting, a bit like the Hurd's translators. Attached to files (using an xattr or something, and executed with the uid/gid of the file owner), and also per-user pattern-action options for matching files with a certain type (e.g. tgz/zip/deb/rpm/xml). But that can be added much later, as it's an orthogonal feature. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: I have a little project to imlement a userloop filesystem, which works just like mount -o loop, but you don't need root privs. This is really simple to do with FUSE and UML. That would be a nice way to implement those rarely used old filesystems that aren't really needed in the kernel source tree any more, but which it would be nice to have access to as legacy filesystem formats. In other words, migrating old legacy filesystems out of the kernel tree, into FUSE. I don't think that it's far feched, that in certain situations the user _does_ have the right (and usefulness) to do otherwise privileged filesystem operations. It's really a matter of philosophy, as to whether the results of stat() are just handy information for the user, or are always defined to mean what you can/can't do with a file. Local-ssh-into-UML makes more sense for this in some ways, because the uids/gids inside your tgz files or foreign loop filesystems are not related to the space of uids/gids of the host system. Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
I have a little project to imlement a userloop filesystem, which works just like mount -o loop, but you don't need root privs. This is really simple to do with FUSE and UML. That would be a nice way to implement those rarely used old filesystems that aren't really needed in the kernel source tree any more, but which it would be nice to have access to as legacy filesystem formats. In other words, migrating old legacy filesystems out of the kernel tree, into FUSE. Not much migration would be needed other than deleting from the current kernel. As long as the lagacy filesystem exists in a kernel that has UML support it should just work. I don't think that it's far feched, that in certain situations the user _does_ have the right (and usefulness) to do otherwise privileged filesystem operations. It's really a matter of philosophy, as to whether the results of stat() are just handy information for the user, or are always defined to mean what you can/can't do with a file. Yes, this is the very heart of the conflict between my and your (Christoph's, etc) view. I argue for more flexibilty, i.e. less policy in kernel, which is a good thing generally. As long as it's secure, what is the problem with it? If users are confused, then they will chose the strict mode. If somebody would like to see more information in the filesystem, they use the relaxed mode. The key here is security IMO. So if you find a security problem with the relaxed mode (together with hiding) then I bow my head. Otherwise who cares if it confuses applications (haven't met any) or users. It doensn't matter. If it confuses anything or anyone, the filesystem writer can fix it. Local-ssh-into-UML makes more sense for this in some ways, because the uids/gids inside your tgz files or foreign loop filesystems are not related to the space of uids/gids of the host system. Ssh into UML is awkward, because you don't necessary have all the tools installed, have networking, etc. And in UML the uid/gid won't make any more sense either. Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. Well you can use ls -n. It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. Well you can use ls -n. It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Well, how do you currently provide access to the information that's not presentable through stat()? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Yet, the results from stat() don't distinguish the number spaces, and ls doesn't map the numbers to names properly in the wrong space. Well you can use ls -n. It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Well, how do you currently provide access to the information that's not presentable through stat()? Obviously I don't. However that's hardly an argument for providing even less information. And stat() btw pretty much covers what information there is to present for network filesystems and archives, since there _is_ a real filesystem where the information originated from (though sometimes it's not a UNIX type of filesystem, in which case there has to be some mapping of the info). Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 12 Apr 2005, Jamie Lokier wrote: > Bodo Eggert <[EMAIL PROTECTED]> wrote: > > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > > Miklos Szeredi wrote: > > > > >> 4) Access should not be further restricted for the owner of the > > >> mount, even if permission bits, uid or gid would suggest > > >> otherwise > > > > > > Why? Surely you want to prevent writing to files which don't have the > > > writable bit set? A filesystem may also create append-only files - > > > and all users including the mount owner should be bound by that. > > > > That will depend on the situation. If the user is mounting a tgz owned > > by himself, FUSE should default to being a convenient hex-editor. > > If the user wants to edit a read-only file in a tgz owned by himself, > why can he not _chmod_ the file and _then_ edit it? > > That said, I would _usually_ prefer that when I enter a tgz, that I > see all component files having the same uid/gid/permissions as the tgz > file itself - the same as I'd see if I entered a zip file. As you say _usually_, even you admit that sometimes you would want the real owner/permissions to be shown. And that is the point Miklos is trying to make I believe: it should be configurable not hard set to only one which is what I understand HCH wants. There are uses for both. For example today I was updating the tar ball which is used to create the var file system for a new chroot. I certainly want to see corretly setup owner/permissions when I look into that tar ball using a FUSE fs... Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, 11 Apr 2005, Jamie Lokier wrote: > Miklos Szeredi wrote: > > That is exactly the intended effect. If I'm at my work machine (where > > I'm not an admin unfortunately) and I mount my home machine with sshfs > > (because FUSE is installed fortunately :), then I bloody well don't > > want the sysadmin or some automated script of his to go mucking under > > the mountpoint. > > I think that would be _much_ nicer implemented as a mount which is > invisible to other users, rather than one which causes the admin's > scripts to spew error messages. Is the namespace mechanism at all > suitable for that? > > It would also be nice to generalise and have virtual filesystems which > are able to present different views to different users. Can FUSE do > that already - is the userspace part told which user is doing each > operation? With that, the desire for virtual filesystems which cannot > be read by your sysadmin (by accident) is easy to satisfy - and that > kind of mechanism would probably be acceptable to all. Yes it does. We use it to provide magic symlinks which point to different places for different people. So we have for example a symlink called "ux" and it points to "/servers/USERNAME/our-server/ux" where USERNAME is the name from /etc/passwd matching the user id of the user accessing the symlink. So in documentaion and in stupid programs which require hardcoding of path we specify "/ux" to find the shared space but in reality this is a different local directory for every user. (To complete the picture the different local directories are actually the same remote directory but mounted with access permissions for each user separately using ncpfs.) Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > Still can't find it :) > > > > Which kernel? Which file? > > I'm looking at linux-2.4.30/fs/nfs/dir.c. Ahh, OK. nfs_permission() in 2.6 looks quite a bit different. And permission bits are not used if ->access() is available. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> There was a thread a few months ago where file-as-directory was > discussed extensively, after Namesys implemented it. That's where the > conversation on detachable mount points originated AFAIR. It will > probably happen at some point. > > A nice implemention of it in FUSE could push it along a bit :) Aren't there some assumptions in VFS that currently make this impossible? I'll go and find that thread. Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Anton Altaparmakov wrote: > > That said, I would _usually_ prefer that when I enter a tgz, that I > > see all component files having the same uid/gid/permissions as the tgz > > file itself - the same as I'd see if I entered a zip file. > > As you say _usually_, even you admit that sometimes you would want the > real owner/permissions to be shown. And that is the point Miklos is > trying to make I believe: it should be configurable not hard set to only > one which is what I understand HCH wants. > > There are uses for both. For example today I was updating the tar ball > which is used to create the var file system for a new chroot. I certainly > want to see corretly setup owner/permissions when I look into that tar > ball using a FUSE fs... If I'm updating a var filesystem for a new chroot, I'd need the ability to chmod and chown things in that filesystem. Does that work as an ordinary user? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, 12 Apr 2005, Jamie Lokier wrote: > Bodo Eggert <[EMAIL PROTECTED]> wrote: > > > I think that would be _much_ nicer implemented as a mount which is > > > invisible to other users, rather than one which causes the admin's > > > scripts to spew error messages. Is the namespace mechanism at all > > > suitable for that? > > > > This will require shared subtrees plus a way for new logins from the same > > user to join an existing (previous login) namespace. > > Or "per-user namespaces". A general way to enter child namespaces would be much more flexible. The mechanism could be reused by projects like linux-vserver. -- Our last fight was my fault: My wife asked me "What's on the TV?" I said, "Dust!" - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > Note that NFS checks the permissions on _both_ the client and server, > > > for a reason. > > > > Does it? If I read the code correctly the client checks credentials > > supplied by the server (or cached). But the server does the actual > > checking of permissions. > > > > Am I missing something? > > Yes, for NFSv2, this test in nfs_permssion(): > > if (!NFS_PROTO(inode)->access) > goto out; I've seen that, I just thought that was for some broken servers not for all NFSv2 servers. Anyway that's been fixed in NFSv3, so obviously the "permission checking on both sides" wasn't optimal :) > And for either version of NFS, if the uid and gid are non-zero, and > the permission bits indicate that an access is permitted, then the > client does not consult the server for permission. Where's that? I see no such check. Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > Still can't find it :) > > Which kernel? Which file? I'm looking at linux-2.4.30/fs/nfs/dir.c. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > Indeed, if it can be done with namespaces _and_ mounting on a file > > (that file-as-directory concept), _and_ automounting, then you could > > cd into your tgz files and others could too :) > > There's still that little problem of accessing the tgz file both as a > file and a directory. But yes. Maybe in 10 years time :) There was a thread a few months ago where file-as-directory was discussed extensively, after Namesys implemented it. That's where the conversation on detachable mount points originated AFAIR. It will probably happen at some point. A nice implemention of it in FUSE could push it along a bit :) -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > The same can be true for tarfs. I mount it for my purpose, others can > mount it for theirs. Since the daemon providing the filesystem asways > runs with the same capabilities as the user who did the mount, I and > others will always get the permissions that we have on the actual tar > file. Fair enough. > Think of the "no permission for others" as "hiding", not as some > special permission rule. And if this hiding can be nicely done with > namespaces, all the better, I'll happily drop this feature at that > instant. Indeed, if it can be done with namespaces _and_ mounting on a file (that file-as-directory concept), _and_ automounting, then you could cd into your tgz files and others could too :) -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > > > And for either version of NFS, if the uid and gid are non-zero, and > > > the permission bits indicate that an access is permitted, then the > > > client does not consult the server for permission. > > > > Where's that? I see no such check. > > /* >* Trust UNIX mode bits except: >* >* 1) When override capabilities may have been invoked >* 2) When root squashing may be involved >* 3) When ACLs may overturn a negative answer */ > if (!capable(CAP_DAC_OVERRIDE) && !capable(CAP_DAC_READ_SEARCH) > && (current->fsuid != 0) && (current->fsgid != 0) > && error != -EACCES) > goto out; Still can't find it :) Which kernel? Which file? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> Indeed, if it can be done with namespaces _and_ mounting on a file > (that file-as-directory concept), _and_ automounting, then you could > cd into your tgz files and others could too :) There's still that little problem of accessing the tgz file both as a file and a directory. But yes. Maybe in 10 years time :) Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote: > Miklos Szeredi wrote: > > > Note that NFS checks the permissions on _both_ the client and server, > > > for a reason. > > > > Does it? If I read the code correctly the client checks credentials > > supplied by the server (or cached). But the server does the actual > > checking of permissions. > > > > Am I missing something? > > Yes, for NFSv2, this test in nfs_permssion(): > > if (!NFS_PROTO(inode)->access) > goto out; > > And for either version of NFS, if the uid and gid are non-zero, and > the permission bits indicate that an access is permitted, then the > client does not consult the server for permission. ... but that clearly says that it checks the permissions on *either* cleint *or* server. Not all requests are passed to the server and there the client only checks the permission bits, even if the credentials are different than what was originally used to obtain the information. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > Yes, for NFSv2, this test in nfs_permssion(): > > > > if (!NFS_PROTO(inode)->access) > > goto out; > > I've seen that, I just thought that was for some broken servers not > for all NFSv2 servers. > > Anyway that's been fixed in NFSv3, so obviously the "permission > checking on both sides" wasn't optimal :) > > > And for either version of NFS, if the uid and gid are non-zero, and > > the permission bits indicate that an access is permitted, then the > > client does not consult the server for permission. > > Where's that? I see no such check. /* * Trust UNIX mode bits except: * * 1) When override capabilities may have been invoked * 2) When root squashing may be involved * 3) When ACLs may overturn a negative answer */ if (!capable(CAP_DAC_OVERRIDE) && !capable(CAP_DAC_READ_SEARCH) && (current->fsuid != 0) && (current->fsgid != 0) && error != -EACCES) goto out; -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > I can accept that usually you are not interested in the stored > > uid/gid. But doubt that you want to lose permission information when > > you mount a tar file. Zip is a different kettle of fish since that > > doesn't contain uid/gid/permissions. > > It's not about being not interested. > > It's because I'd want my programs, and other users, to have exactly > the same access to the tgz contents through vfs as they have when > accessing the tgz file directly. OK, that makes sense, and it should be an option. > Not some baroque combination of unobvious hard-coded permission > rules, that aren't even visible through stat(), and which both > increase permissions for the user and decrease it for others at the > same time. I look at it differently. I want the tar filesystem to be analogous to running tar. When I run tar, other users are not notified of the output, it's only for me. If they want to run tar, they can too. The same can be true for tarfs. I mount it for my purpose, others can mount it for theirs. Since the daemon providing the filesystem asways runs with the same capabilities as the user who did the mount, I and others will always get the permissions that we have on the actual tar file. The end result in permission rules is the _same_ as with your proposal. There's nothing baroque in it. Think of the "no permission for others" as "hiding", not as some special permission rule. And if this hiding can be nicely done with namespaces, all the better, I'll happily drop this feature at that instant. > I see why you may want to hide certain things from other users > sometimes - the sshfs example is a good one. I daresay Al Viro could > come up with a per-user or per-keyring mount point for those occasions :) Yeah, maybe that's something worth exploring. Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > Note that NFS checks the permissions on _both_ the client and server, > > for a reason. > > Does it? If I read the code correctly the client checks credentials > supplied by the server (or cached). But the server does the actual > checking of permissions. > > Am I missing something? Yes, for NFSv2, this test in nfs_permssion(): if (!NFS_PROTO(inode)->access) goto out; And for either version of NFS, if the uid and gid are non-zero, and the permission bits indicate that an access is permitted, then the client does not consult the server for permission. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > If the user wants to edit a read-only file in a tgz owned by himself, > > why can he not _chmod_ the file and _then_ edit it? > > > > That said, I would _usually_ prefer that when I enter a tgz, that I > > see all component files having the same uid/gid/permissions as the tgz > > file itself - the same as I'd see if I entered a zip file. > > I can accept that usually you are not interested in the stored > uid/gid. But doubt that you want to lose permission information when > you mount a tar file. Zip is a different kettle of fish since that > doesn't contain uid/gid/permissions. It's not about being not interested. It's because I'd want my programs, and other users, to have exactly the same access to the tgz contents through vfs as they have when accessing the tgz file directly. Not some baroque combination of unobvious hard-coded permission rules, that aren't even visible through stat(), and which both increase permissions for the user and decrease it for others at the same time. I see why you may want to hide certain things from other users sometimes - the sshfs example is a good one. I daresay Al Viro could come up with a per-user or per-keyring mount point for those occasions :) -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> For 1) your porposal makes sense, however for 2) it's useless, since > now the user doesn't want the hiding. I realize that the idea _could_ be used to drop 'allow_root' mount option from the kernel. Since 'allow_root' doesn't add any security over 'allow_other' it's safe to do it in userspace. Goodie :) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Frank Sorenson wrote: > > That does not make sense. > > > > Are you saying you cannot trust your own sshfs userspace daemon? > > The user who wrote the userspace code may be able to, but the system > shouldn't trust the userspace daemon. Permissions will be enforced by > the ssh server. In fact that's wrong. Although permissions are enforced by the ssh server, the server assumes that once a conncection is established, all requests on it are from the same originating user. The server is not able to check which user is accessing the files on the client machine - which is why Miklos wants/needs restrictive permissions on the client machine too. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> If the user wants to edit a read-only file in a tgz owned by himself, > why can he not _chmod_ the file and _then_ edit it? > > That said, I would _usually_ prefer that when I enter a tgz, that I > see all component files having the same uid/gid/permissions as the tgz > file itself - the same as I'd see if I entered a zip file. I can accept that usually you are not interested in the stored uid/gid. But doubt that you want to lose permission information when you mount a tar file. Zip is a different kettle of fish since that doesn't contain uid/gid/permissions. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: > That does not make sense. > > Are you saying you cannot trust your own sshfs userspace daemon? The user who wrote the userspace code may be able to, but the system shouldn't trust the userspace daemon. Permissions will be enforced by the ssh server. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCW+ZLaI0dwg4A47wRAnDVAKCb2Hk39ouYkjEDgTlz+RTsPsAn5QCgpKvZ rfYjOi+x6+RSie+t8GIxX74= =qShM -END PGP SIGNATURE- - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> > > With that, the desire for virtual filesystems which cannot be read > > > by your sysadmin (by accident) is easy to satisfy - and that kind of > > > mechanism would probably be acceptable to all. > > > > The problem is that this way the responsibility goes to the userspace > > program, which can't be trusted. > > That does not make sense. > > Are you saying you cannot trust your own sshfs userspace daemon? OK, I was not clear here. When I say it cannot be trusted I'm in my sysadmin cap, not my user cap. Hiding the mountpoint from root has dual purpose: 1) Sysadmin won't accidentaly spy on user's private files 2) User can't confuse sysadmin deliberately, by creating a filesystem containing files he otherwise wouldn't be able to create For 1) your porposal makes sense, however for 2) it's useless, since now the user doesn't want the hiding. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> Note that NFS checks the permissions on _both_ the client and server, > for a reason. Does it? If I read the code correctly the client checks credentials supplied by the server (or cached). But the server does the actual checking of permissions. Am I missing something? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Bodo Eggert <[EMAIL PROTECTED]> wrote: > >> That is exactly the intended effect. If I'm at my work machine (where > >> I'm not an admin unfortunately) and I mount my home machine with sshfs > >> (because FUSE is installed fortunately :), then I bloody well don't > >> want the sysadmin or some automated script of his to go mucking under > >> the mountpoint. > > > > I think that would be _much_ nicer implemented as a mount which is > > invisible to other users, rather than one which causes the admin's > > scripts to spew error messages. Is the namespace mechanism at all > > suitable for that? > > This will require shared subtrees plus a way for new logins from the same > user to join an existing (previous login) namespace. Or "per-user namespaces". It's part of a more general problem of how you limit access to private data such as crypto keys, either per user, or more finely than that. Isn't that what all the keyring stuff is for? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Bodo Eggert <[EMAIL PROTECTED]> wrote: > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > Miklos Szeredi wrote: > > >> 4) Access should not be further restricted for the owner of the > >> mount, even if permission bits, uid or gid would suggest > >> otherwise > > > > Why? Surely you want to prevent writing to files which don't have the > > writable bit set? A filesystem may also create append-only files - > > and all users including the mount owner should be bound by that. > > That will depend on the situation. If the user is mounting a tgz owned > by himself, FUSE should default to being a convenient hex-editor. If the user wants to edit a read-only file in a tgz owned by himself, why can he not _chmod_ the file and _then_ edit it? That said, I would _usually_ prefer that when I enter a tgz, that I see all component files having the same uid/gid/permissions as the tgz file itself - the same as I'd see if I entered a zip file. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > The same is true for the case when you mount an sshfs. Since you > entered your password (or have a passwordless login to the server) you > are authorized to browse the files on the server, but only with the > capabilities you have there as a user. The server does the > authorization. The same is true for an NFS mount btw. It's not the > client that checks the permissions. > > So do you see why I argue in favor of having an option _not_ to check > permissions on the client by the kernel? Note that NFS checks the permissions on _both_ the client and server, for a reason. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: > > It would also be nice to generalise and have virtual filesystems which > > are able to present different views to different users. Can FUSE do > > that already - is the userspace part told which user is doing each > > operation? > > Yes. > > > With that, the desire for virtual filesystems which cannot be read > > by your sysadmin (by accident) is easy to satisfy - and that kind of > > mechanism would probably be acceptable to all. > > The problem is that this way the responsibility goes to the userspace > program, which can't be trusted. That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Jamie Lokier <[EMAIL PROTECTED]> wrote: > Miklos Szeredi wrote: >> 4) Access should not be further restricted for the owner of the >> mount, even if permission bits, uid or gid would suggest >> otherwise > > Why? Surely you want to prevent writing to files which don't have the > writable bit set? A filesystem may also create append-only files - > and all users including the mount owner should be bound by that. That will depend on the situation. If the user is mounting a tgz owned by himself, FUSE should default to being a convenient hex-editor. >> 5) As much of the available information should be exported via the >> filesystem as possible > > This is the root of the conflict. You are trying to overload the > permission bits and uid/gid to mean something different than they > normally do. > > While it's convenient to see some "remote" information such as the > uid/gid in a tar file, are you sure it's a good idea to break the unix > permissions model - which will break some programs? (For example, try > editing a file with the broken semantics in an editor which checks the > uid/gid of the file against the current user). The editor will try to keep the original permissions, and saving will be less effective. >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) > > Seems good - but why not sticky? Mounting a user filesystem in > /tmp/user-xxx/my-mount-point seems not unreasonable - provided the > administrator can delete the directory (which is possible with > detachable mount points). I once mounted a filesystem in ~/tmp after forgetting about it being a symlink to /tmp/$me/tmp, and I had to promise never to do that again. Ng zvqavtug, gur pyrnahc-grzc-fpevcg xvpxrq va. >> 5) The filesystem daemon is free to fill in all file attributes to >> any (sane) value, and the kernel won't modify these. > > Dangerous, because an administrative program might actually trust the > attributes to mean what they normally mean in the unix permissions model. The same risk applies to smbmounted file systems. Sane daemons will do no check besides matching the owner of a file in the user's home against the expected UID and checking the permission mask, since you can't trust users not to mess with files in directories they own. The "best" they can do should be shoothing their own feet. (If the user doesn't own the directory, FUSE shouldn't mount.) -- Top 100 things you don't want the sysadmin to say: 80. I cleaned up the root partition and now there's LOTS of free space. Friß, Spammer:[EMAIL PROTECTED]@whitedoc.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: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote: > > Could you explain a little more? I don't see the point in denying > > access to root, but I also can't tell from your explanation whether you > > do or not. > > Fuse by default does. This can be disabled by one of two mount > options: "allow_other" and "allow_root". The former implies the > later. These mount options are only allowed for mounting by root, but > this can be relaxed with a configuration option. > > > If I mount a filesystem using ssh, I want to be able to "sudo cp > > foo.txt /etc" and not get an inexplicable permissions error. > > If you can do that sudo, you can also modify the configuration and use > one of the mount options. And that's as false as it can be! Ok, no sane admin would probably give out sudo permissions for cp, but other commands may make sense (perhaps setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one could teach sudo to set euid, but not fsuid). And than the user would *NOT* be able to use those mount options. Anyway, why are the options not available to non-root? It's their filesystem, they should be allowed to set it up! > > > 4) Access should not be further restricted for the owner of the > > > mount, even if permission bits, uid or gid would suggest > > > otherwise > > > > Similar questions. > > This behavior can be disabled by the "default_permissions" mount > option (wich is not privileged, since it adds restrictions). A FUSE > filesystem mounted by root (and not for private purposes) would > normally be done with "allow_other,default_permissions". I'd hell lot prefer it the other way around. The user write bit is an accident counter-measure similarly to the root squashing. It needs to be split to two orthogonal options -- one to specify, whether all files are owned by the mounter or by whomever the filesystem says and another whether permissions are checked. --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
> > Well the sanity check on the "server" side is always enforced. You > > can't "trick" sftp or ftp to not check permissions. So checking on > > the "client" side too (where the fuse daemon is running) makes no > > sense, does it? > > That argument doesn't make much sense to me. But we're at the end of > my useful contributions to this discussion; I'm going to be quiet now > and hope some folks who know more about filesystems have more useful > responses. I'm sorry if this isn't clear enough. My explanatory powers are not very strong, so please bear with me. Imagine an sftp session. You list the files on the remote server. You want download a file for which there are very limited permission (e.g. only readable to owner). You don't _know_ if you are the owner since the uid on the file does not ring any bells, but you still try, since you want that file badly. And you succeed. Would it make sense if the sftp client would try to interpret the uid/gid/permission on each file? Obviously not. The same is true for the case when you mount an sshfs. Since you entered your password (or have a passwordless login to the server) you are authorized to browse the files on the server, but only with the capabilities you have there as a user. The server does the authorization. The same is true for an NFS mount btw. It's not the client that checks the permissions. So do you see why I argue in favor of having an option _not_ to check permissions on the client by the kernel? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
> I think that would be _much_ nicer implemented as a mount which is > invisible to other users, rather than one which causes the admin's > scripts to spew error messages. Spew is a strong word. It'll get a single EACCES at the mountpoint. The same is true for directories not accessible by 'nobody' under an NFS mount exported with root squash. > Is the namespace mechanism at all suitable for that? It is certainly the right tool for this. However currently private namespaces are quite limited. The only sane usage I can think of is that before mounting the user starts a shell with CLONE_NS, and does the mount in this. However all the other programs he already has running (editor, browser, desktop environment) won't be able to access the mount. Shared subtrees and more support in userspace tools is needed before private namespaces can become really useful. > It would also be nice to generalise and have virtual filesystems which > are able to present different views to different users. Can FUSE do > that already - is the userspace part told which user is doing each > operation? Yes. > With that, the desire for virtual filesystems which cannot be read > by your sysadmin (by accident) is easy to satisfy - and that kind of > mechanism would probably be acceptable to all. The problem is that this way the responsibility goes to the userspace program, which can't be trusted. Either the kernel has to enforce that uid/gid on each file are set to the mount owner, or the kernel has to enforce that no other user has access to the mountpoint. Some policy _must_ be kept in kernel. I think both these policies have valid uses, so I wouldn't want to limit FUSE to a single one. Hmm? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
I think that would be _much_ nicer implemented as a mount which is invisible to other users, rather than one which causes the admin's scripts to spew error messages. Spew is a strong word. It'll get a single EACCES at the mountpoint. The same is true for directories not accessible by 'nobody' under an NFS mount exported with root squash. Is the namespace mechanism at all suitable for that? It is certainly the right tool for this. However currently private namespaces are quite limited. The only sane usage I can think of is that before mounting the user starts a shell with CLONE_NS, and does the mount in this. However all the other programs he already has running (editor, browser, desktop environment) won't be able to access the mount. Shared subtrees and more support in userspace tools is needed before private namespaces can become really useful. It would also be nice to generalise and have virtual filesystems which are able to present different views to different users. Can FUSE do that already - is the userspace part told which user is doing each operation? Yes. With that, the desire for virtual filesystems which cannot be read by your sysadmin (by accident) is easy to satisfy - and that kind of mechanism would probably be acceptable to all. The problem is that this way the responsibility goes to the userspace program, which can't be trusted. Either the kernel has to enforce that uid/gid on each file are set to the mount owner, or the kernel has to enforce that no other user has access to the mountpoint. Some policy _must_ be kept in kernel. I think both these policies have valid uses, so I wouldn't want to limit FUSE to a single one. Hmm? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Well the sanity check on the server side is always enforced. You can't trick sftp or ftp to not check permissions. So checking on the client side too (where the fuse daemon is running) makes no sense, does it? That argument doesn't make much sense to me. But we're at the end of my useful contributions to this discussion; I'm going to be quiet now and hope some folks who know more about filesystems have more useful responses. I'm sorry if this isn't clear enough. My explanatory powers are not very strong, so please bear with me. Imagine an sftp session. You list the files on the remote server. You want download a file for which there are very limited permission (e.g. only readable to owner). You don't _know_ if you are the owner since the uid on the file does not ring any bells, but you still try, since you want that file badly. And you succeed. Would it make sense if the sftp client would try to interpret the uid/gid/permission on each file? Obviously not. The same is true for the case when you mount an sshfs. Since you entered your password (or have a passwordless login to the server) you are authorized to browse the files on the server, but only with the capabilities you have there as a user. The server does the authorization. The same is true for an NFS mount btw. It's not the client that checks the permissions. So do you see why I argue in favor of having an option _not_ to check permissions on the client by the kernel? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote: Could you explain a little more? I don't see the point in denying access to root, but I also can't tell from your explanation whether you do or not. Fuse by default does. This can be disabled by one of two mount options: allow_other and allow_root. The former implies the later. These mount options are only allowed for mounting by root, but this can be relaxed with a configuration option. If I mount a filesystem using ssh, I want to be able to sudo cp foo.txt /etc and not get an inexplicable permissions error. If you can do that sudo, you can also modify the configuration and use one of the mount options. And that's as false as it can be! Ok, no sane admin would probably give out sudo permissions for cp, but other commands may make sense (perhaps setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one could teach sudo to set euid, but not fsuid). And than the user would *NOT* be able to use those mount options. Anyway, why are the options not available to non-root? It's their filesystem, they should be allowed to set it up! 4) Access should not be further restricted for the owner of the mount, even if permission bits, uid or gid would suggest otherwise Similar questions. This behavior can be disabled by the default_permissions mount option (wich is not privileged, since it adds restrictions). A FUSE filesystem mounted by root (and not for private purposes) would normally be done with allow_other,default_permissions. I'd hell lot prefer it the other way around. The user write bit is an accident counter-measure similarly to the root squashing. It needs to be split to two orthogonal options -- one to specify, whether all files are owned by the mounter or by whomever the filesystem says and another whether permissions are checked. --- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Jamie Lokier [EMAIL PROTECTED] wrote: Miklos Szeredi wrote: 4) Access should not be further restricted for the owner of the mount, even if permission bits, uid or gid would suggest otherwise Why? Surely you want to prevent writing to files which don't have the writable bit set? A filesystem may also create append-only files - and all users including the mount owner should be bound by that. That will depend on the situation. If the user is mounting a tgz owned by himself, FUSE should default to being a convenient hex-editor. 5) As much of the available information should be exported via the filesystem as possible This is the root of the conflict. You are trying to overload the permission bits and uid/gid to mean something different than they normally do. While it's convenient to see some remote information such as the uid/gid in a tar file, are you sure it's a good idea to break the unix permissions model - which will break some programs? (For example, try editing a file with the broken semantics in an editor which checks the uid/gid of the file against the current user). The editor will try to keep the original permissions, and saving will be less effective. 1) Only allow mount over a directory for which the user has write access (and is not sticky) Seems good - but why not sticky? Mounting a user filesystem in /tmp/user-xxx/my-mount-point seems not unreasonable - provided the administrator can delete the directory (which is possible with detachable mount points). I once mounted a filesystem in ~/tmp after forgetting about it being a symlink to /tmp/$me/tmp, and I had to promise never to do that again. Ng zvqavtug, gur pyrnahc-grzc-fpevcg xvpxrq va. 5) The filesystem daemon is free to fill in all file attributes to any (sane) value, and the kernel won't modify these. Dangerous, because an administrative program might actually trust the attributes to mean what they normally mean in the unix permissions model. The same risk applies to smbmounted file systems. Sane daemons will do no check besides matching the owner of a file in the user's home against the expected UID and checking the permission mask, since you can't trust users not to mess with files in directories they own. The best they can do should be shoothing their own feet. (If the user doesn't own the directory, FUSE shouldn't mount.) -- Top 100 things you don't want the sysadmin to say: 80. I cleaned up the root partition and now there's LOTS of free space. Friß, Spammer:[EMAIL PROTECTED]@whitedoc.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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: It would also be nice to generalise and have virtual filesystems which are able to present different views to different users. Can FUSE do that already - is the userspace part told which user is doing each operation? Yes. With that, the desire for virtual filesystems which cannot be read by your sysadmin (by accident) is easy to satisfy - and that kind of mechanism would probably be acceptable to all. The problem is that this way the responsibility goes to the userspace program, which can't be trusted. That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: The same is true for the case when you mount an sshfs. Since you entered your password (or have a passwordless login to the server) you are authorized to browse the files on the server, but only with the capabilities you have there as a user. The server does the authorization. The same is true for an NFS mount btw. It's not the client that checks the permissions. So do you see why I argue in favor of having an option _not_ to check permissions on the client by the kernel? Note that NFS checks the permissions on _both_ the client and server, for a reason. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Bodo Eggert [EMAIL PROTECTED] wrote: Jamie Lokier [EMAIL PROTECTED] wrote: Miklos Szeredi wrote: 4) Access should not be further restricted for the owner of the mount, even if permission bits, uid or gid would suggest otherwise Why? Surely you want to prevent writing to files which don't have the writable bit set? A filesystem may also create append-only files - and all users including the mount owner should be bound by that. That will depend on the situation. If the user is mounting a tgz owned by himself, FUSE should default to being a convenient hex-editor. If the user wants to edit a read-only file in a tgz owned by himself, why can he not _chmod_ the file and _then_ edit it? That said, I would _usually_ prefer that when I enter a tgz, that I see all component files having the same uid/gid/permissions as the tgz file itself - the same as I'd see if I entered a zip file. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Bodo Eggert [EMAIL PROTECTED] wrote: That is exactly the intended effect. If I'm at my work machine (where I'm not an admin unfortunately) and I mount my home machine with sshfs (because FUSE is installed fortunately :), then I bloody well don't want the sysadmin or some automated script of his to go mucking under the mountpoint. I think that would be _much_ nicer implemented as a mount which is invisible to other users, rather than one which causes the admin's scripts to spew error messages. Is the namespace mechanism at all suitable for that? This will require shared subtrees plus a way for new logins from the same user to join an existing (previous login) namespace. Or per-user namespaces. It's part of a more general problem of how you limit access to private data such as crypto keys, either per user, or more finely than that. Isn't that what all the keyring stuff is for? -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Note that NFS checks the permissions on _both_ the client and server, for a reason. Does it? If I read the code correctly the client checks credentials supplied by the server (or cached). But the server does the actual checking of permissions. Am I missing something? Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
With that, the desire for virtual filesystems which cannot be read by your sysadmin (by accident) is easy to satisfy - and that kind of mechanism would probably be acceptable to all. The problem is that this way the responsibility goes to the userspace program, which can't be trusted. That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? OK, I was not clear here. When I say it cannot be trusted I'm in my sysadmin cap, not my user cap. Hiding the mountpoint from root has dual purpose: 1) Sysadmin won't accidentaly spy on user's private files 2) User can't confuse sysadmin deliberately, by creating a filesystem containing files he otherwise wouldn't be able to create For 1) your porposal makes sense, however for 2) it's useless, since now the user doesn't want the hiding. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? The user who wrote the userspace code may be able to, but the system shouldn't trust the userspace daemon. Permissions will be enforced by the ssh server. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCW+ZLaI0dwg4A47wRAnDVAKCb2Hk39ouYkjEDgTlz+RTsPsAn5QCgpKvZ rfYjOi+x6+RSie+t8GIxX74= =qShM -END PGP SIGNATURE- - 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: [RFC] FUSE permission modell (Was: fuse review bits)
If the user wants to edit a read-only file in a tgz owned by himself, why can he not _chmod_ the file and _then_ edit it? That said, I would _usually_ prefer that when I enter a tgz, that I see all component files having the same uid/gid/permissions as the tgz file itself - the same as I'd see if I entered a zip file. I can accept that usually you are not interested in the stored uid/gid. But doubt that you want to lose permission information when you mount a tar file. Zip is a different kettle of fish since that doesn't contain uid/gid/permissions. Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Frank Sorenson wrote: That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? The user who wrote the userspace code may be able to, but the system shouldn't trust the userspace daemon. Permissions will be enforced by the ssh server. In fact that's wrong. Although permissions are enforced by the ssh server, the server assumes that once a conncection is established, all requests on it are from the same originating user. The server is not able to check which user is accessing the files on the client machine - which is why Miklos wants/needs restrictive permissions on the client machine too. -- Jamie - 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: [RFC] FUSE permission modell (Was: fuse review bits)
For 1) your porposal makes sense, however for 2) it's useless, since now the user doesn't want the hiding. I realize that the idea _could_ be used to drop 'allow_root' mount option from the kernel. Since 'allow_root' doesn't add any security over 'allow_other' it's safe to do it in userspace. Goodie :) Thanks, Miklos - 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: [RFC] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: If the user wants to edit a read-only file in a tgz owned by himself, why can he not _chmod_ the file and _then_ edit it? That said, I would _usually_ prefer that when I enter a tgz, that I see all component files having the same uid/gid/permissions as the tgz file itself - the same as I'd see if I entered a zip file. I can accept that usually you are not interested in the stored uid/gid. But doubt that you want to lose permission information when you mount a tar file. Zip is a different kettle of fish since that doesn't contain uid/gid/permissions. It's not about being not interested. It's because I'd want my programs, and other users, to have exactly the same access to the tgz contents through vfs as they have when accessing the tgz file directly. Not some baroque combination of unobvious hard-coded permission rules, that aren't even visible through stat(), and which both increase permissions for the user and decrease it for others at the same time. I see why you may want to hide certain things from other users sometimes - the sshfs example is a good one. I daresay Al Viro could come up with a per-user or per-keyring mount point for those occasions :) -- Jamie - 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/
