Messages in this thread | | | Subject | Re: Possible permissions bug on NFSv3 kernel client | From | Colin Paton <> | Date | Tue, 04 May 2004 10:55:20 +0100 |
| |
Hi,
> So why do you think that is inconsistent with my statement: "the > permissions checking has to be done by the server, period"?
I agree that permission checking should be done by the server. However, I believe that in this case the client is requesting the wrong permissions. As writing to a char/block device does not perform a write operation *on the server* then the client should not be asking the server for modify/extend permission in the case of char/block devices.
> The read-only mount option does *not apply* to char/block devices such > as /dev/hd[a-z]*, /dev/tty*. Permission checks on open() for those > devices are done on the server *only* via the ACCESS rpc call.
Should vfs_permission() (as called from nfs_permission) be sufficient to perform this check?
> > This should be entirely consistent with local file behaviour.
I don't believe that it is... it is possible to write to a block device on a filesystem that is mounted read-only, but not to write to a block device on an NFS filesystem that is *exported* read-only.
I think that nfs_permission() may do sufficient checking - I believe the problem is in nfs3_proc_access() - where the client is asking the server for more permissions than it needs.
Colin
- 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/
| |