Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Miklos Szeredi <miklos@szeredi.hu>]

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