Re: [PATCH] private mounts

[Miklos Szeredi <miklos@szeredi.hu>]

> 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/