--On Saturday, July 12, 2008 01:25:14 AM -0400 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
Read makes sense. The FS - CM Programmer's Reference doesn't specify
what the privileges should be so I would go with the code.
No, actually, read does not make sense.
The lookup, insert, and delete rights on a directory describe things you
are allowed to do to the directory itself. The read, write, and lock
rights describe things you are allowed to to do plain files within a
directory (there are, of course, a couple of bizarre exceptions).
Requiring 'read' access (the ability to read the contents of any file with
an 'r' or 'x' bit set) to perform directory- or volume-level operations
seems inappropriate.
That said, the current behavior does require read for those operations, and
it's been that way for some time. I agree that the documentation and code
should match, and that the "bug fix" way to achieve that is to fix the
documentation.
We should consider whether the fileserver should allow
RXAFS_GetVolumeStatus (an RPC which takes a volume ID, not a FID) for a
client that does not have read access on the volume's root directory. I'm
inclined to say that it should not examine the access rights at all,
because nearly all of the information available from RXAFS_GetVolumeStatus
is also available from AFSVolListOneVolume (the exceptions are the
partition stats, which are available from AFSVolPartitionInfo, and the motd
and minfree, which are only conveniently available from the fileserver but
are also meaningless).
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
