[AFS3-std] Changing RXAFS_GetVolumeStatus access check to support volume lock down

[Jeffrey Hutzelman]

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