Many sites over the last two years have focused energy on locking down their cells. This is being done to protect against information leakage and to protect the organization from end users that do not appreciate the consequences of changing the access control lists.
Some sites have made the decision that volumes assigned to end users will not be owned by the user and that the volume root directory will only ever have (l)ookup. All directories the user can read or write to in the volume will be subdirectories. This approach works fine for the UNIX clients but results in some strange behaviors with the 1.7.x Windows clients. The 1.7.x Windows clients treat each AFS volume as its own file system object. The benefits of this approach are many but one of the primary ones is that each file system has its own block allocations, blocks in use counters, and per user quotas. In 1.6 and prior releases the entirety of the \\AFS name space was treated as a single file system and the client lied to Windows about the size of the file system and the amount of free space. 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. The specific fields that are returned are: Message of the day (if any) Offline message (if any) Online flag InService flag Blessed flag NeedsSalvage flag Type MinQuota MaxQuota BlocksInUse PartBlocksAvail PartMaxBlocks While "vos examine" can obtain this information without any form of authentication, the IBM/OpenAFS file servers have always required that the [un]authenticated caller have (r)ead permission on the root directory of the volume. As a result, users whom only have (l)ookup permission to the root directory but write permission to subdirectories are permitted to write data but must do so blind with regards to the amount of free space or free quota. One side effect of writing blind on a Windows system with a large amount of unused memory is that Windows will happily write the entire file into the system page cache before flushing the data to disk on the last handle close. As a result, an application can believe it has successfully written the data only to have it be tossed out the window when it turns out there is no space. By the time the last handle is closed it is too late to return an error to the application. Lars discovered this problem back in April. As a result the Windows client now performs an explicit free space check on each extending write. While not fool proof, such a check does permit the explorer shell and applications to deliver meaningful errors to the end user while preventing unexpected data loss. Unfortunately, a meaningful free space and free quota check requires the ability to successfully issue the RXAFS_GetVolumeStatus RPC. If the volume is locked down for the user such that the user only has (l)ookup privilege it will fail. 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? The protocol documentation provided by IBM does not discuss the required permissions or the rationale for them. I believe the current check for PRSFS_READ is a coding error and it should be fixed. As noted previously, all of the information is publicly available via "vos examine". As a result making this change does not create an additional information exposure. In gerrit, http://gerrit.openafs.org/#change,7705 contains the patchset to make this change. Please send all follow-ups to this e-mail to [email protected]. Let the discussion of the merits of this change begin. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
