lkml.org 
[lkml]   [2004]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Possible permissions bug on NFSv3 kernel client
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.159 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site