On Wed, 2012-07-04 at 11:14 -0400, Jeffrey Altman wrote: > The RPC that is used to obtain the volume statistics from the file > server is RXAFS_GetVolumeStatus. This RPC returns a subset of the > information displayed by "vos examine <volume>" but is intended for use > by AFS clients.
Well, not entirely. IIRC, it's quite a lot older than that, and predates the concept of a volserver or volume location server. In those days, the fileserver was the _only_ server that touched volumes; doing administrative volume operations required separate utilities on the fileserver, and moving volumes must have been a royal pain. > I believe that the permission check enforced by the file server is > incorrect. The correct permission check should be for PRSFS_LOOKUP and > not PRSFS_READ. If the client can enumerate the root directory of the > volume it should be able to obtain the volume statistics. Not that they > are used any longer but what use is setting the Message of the Day and > the Offline reason messages on a volume if a subset of the clients that > are permitted to access the volume cannot read them? In fact, the offline reason message is only ever set on an offline volume, which the fileserver cannot even access. I think it is fine to skip access control checks on this call entirely. As you point out, the information available via this RPC is also available to unauthenticated clients via the volserver. I do not believe this is a standardization issue. The meaning of some access control bits _as they apply to vnodes_ must be standardized, as clients rely on those bits when implementing access controls on cached objects shared between users. And of course, their representation on the wire must be standardized in order for the tools and interfaces used to manipulate vnode access controls to interoperate. However, the precise application of access controls to non-cacheable operations, volume-level operations, and administrative operations is not standardized and does not need to be standardized in order to obtain interoperability. Thus, I believe the present question is entirely a matter for the implementation and, perhaps, local policy. As such, I've moved afs3-standardization to the Bcc line. Please feel free to move it back in replies, but only if you actively disagree with my position that this is not a standardization issue. -- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
