> On May 25, 2016, at 8:15 AM, Christoph Hellwig <hch@xxxxxx> wrote:
>
>
>> + * effectively be WRITE only.
>> + */
>> + fl->flags = FF_FLAGS_NO_LAYOUTCOMMIT | FF_FLAGS_NO_IO_THRU_MDS |
>> + FF_FLAGS_NO_READ_IO;
>> +
>> + fl->uid = inode->i_uid;
>> + fl->gid = inode->i_gid;
>
> Maybe I need to actually read the latest draft, but what's the story
> about these on the wire uids/gids?
>
Since NFSv3 does not grok stateids, this allows us to control access to
the file.
The mode is adjusted such that the owner has read/write and
the group has read access:
loghyr:~ loghyr$ ls -la foo
-rw-r----- 1 loghyr staff 0 May 25 22:27 foo
When the mds decides to fence off access for the IOMODE_RW
segment, it changes the uid (monotonically increasing reduces the
chance of resetting to some older value). When it wants to fence
off the IOMODE_READ segment, it changes the gid.
So the code above, should really be something like:
if (seg->iomode == IOMODE_READ)
fl->uid = inode->i_uid + 11;
else
fl->uid = inode->i_uid;
fl->gid = inode->i_gid;
This prevents some client from using the IOMODE_READ segment
to do writes. (I think Jeff just fixed that recently in the client.)
As this patchset neither has fencing nor a remote DS, the synthetic
uid/gid works because the file modes have already determined if
access is to be granted. There are “issues” in that the mode bits
may not be 0640.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
