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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig33AA9F612AD432B54A610609
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=
=2E

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 openafs-info@openafs.org.

Let the discussion of the merits of this change begin.

Jeffrey Altman



--------------enig33AA9F612AD432B54A610609
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJP9F3cAAoJENxm1CNJffh4/HAIAMIwRJDQ2xZOa15IgthruK4s
UjpybxNAg3qhcv1H/pyMHBExf7Qml85mJnqBCRTpu6n8KdN+/wHSgimdl0sWEHOG
wnAqsx+P1I1ZL21WyzGK26zhqWJ7k1X6mTy/4E2KUGCyy0lCSYUMqnSL2mw6WoWv
AbeucJnPRWxSeXlHHHtQe6PP0ACPX/EzwFuVQ+7L3WagH2Fwv+apmbo7/GsuJTak
2Ff23QmIk8fEANC4NdjHg+xp8jX23O4WHhEjXn9Bckc6s5FcQ3RAExDfH4RJL7IX
Xcl2ZLRczOIZkaupBNGOpTKLGgYm4KKsgc53TuAUJseiDaOQNsmOiZyVmSM7kKs=
=uB7O
-----END PGP SIGNATURE-----

--------------enig33AA9F612AD432B54A610609--