Messages in this thread | | | Subject | Re: Possible permissions bug on NFSv3 kernel client | From | Trond Myklebust <> | Date | Tue, 04 May 2004 09:52:17 -0400 |
| |
On Tue, 2004-05-04 at 05:55, Colin Paton wrote: > 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.
Sure it should: you are asking it for write permission! If you didn't check the for modify/extend, then you be allowing world write permission by default.
I just checked that Sun's NFS client indeed checks both "extend" and "modify" when attempting to write to a character device.
> > 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?
No! I repeat: vfs_permission() knows nothing about any uid/gid mapping/squashing. You cannot rely exclusively on the mode bits in NFS.
> 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.
That sounds like a server bug, then.
Cheers, Trond - 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/
| |