Messages in this thread | | | Subject | Re: [PATCH] private mounts | From | Miklos Szeredi <> | Date | Tue, 26 Apr 2005 14:08:10 +0200 |
| |
> Problem 1: > > - you're mounting things into the global namespace, but expect it only > be visible to a certain subset of processes. these processes are also > not specicified by a tradition unix session / process group / etc but > against all the process attributes we have based on the uid
Yes, so? You are harping on this without ever telling a concrete technical problem with it.
Yes root will assume it's a directory that can be read. And it will get -EACCESS. Is there a problem with this? Is there a problem with NFS exports with root_squash (which is the default btw)? See the similarity?
> Problem 2, which is related: > > - in fuse you're re-routing filesystem request to userspace, so fine so good > - mount is currently a privilegued operation, and expects a privilegued > filesystem implementation, not an ordinary user > - to bypass that you have a suid mount wrapper > - now you need various hacks to make sure this can't be used by other users
Why is this a hack? What is the problem with it?
NFSv3 implements it's own permission checking based on credentials returned by the server. If client doesn't support Posix ACL and server does, the permission bits _will_ be out of sync with the actual permission you get on the file, and you will never know why. Is it a problem? Can it be avoided?
How would sshfs client create permission bits for files, which match the exact permissions that the user has on the server. The client doesn't even know the uid of the user on the remote system let alone what groups it belongs to.
Think about these problems, and if you have a _solution_ that you think is better, then pray tell me. If you don't have a solution, but just want to bad-mouth the current FUSE imlementation, I'm not interested.
Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |