OpenAFS CVS Commit: openafs/src/WINNT/afsd by jaltman

[cvs@GRAND.CENTRAL.ORG]

Update of /cvs/openafs/src/WINNT/afsd
In directory GRAND.CENTRAL.ORG:/home/jaltman/openafs/cvs-1-5/src/WINNT/afsd

Modified Files:
      Tag: openafs-devel-1_5_x
	cm_access.c cm_vnodeops.c 
Log Message:
DELTA DEVEL15-windows-dropbox-fix-20070426
AUTHOR asanka@secure-endpoints.com
FIXES 60161

A dropbox is a directory with ACLs 'li' that permits a user to create
a new file but not be able to read other files within the same directory.

The 1.5 Windows clients have not been able to write to dropboxes since
the addition of the locking code.  The lock acquisition test assumed
that if the user did not have PRSFS_LOCK or PRSFS_WRITE that it would
be unable to obtain a lock.  It did not take into account the special
treatment of PRSFS_INSERT by the file server and so never bothered to
ask.

As it turns out though, the locking situation is more complex than one
might think.  If the server is 1.4.1 or earlier, it will not grant
any locks for users with INSERT.  The PRSFS_LOCK privilege is required.

For 1.4.2 through 1.4.4, write locks will be granted if the user has
PRSFS_INSERT but a read lock will not be granted unless the user has
PRSFS_LOCK.  Therefore, if the server advertises the WRITELOCKACL
capability bit if the read lock is not granted a write lock can be
attempted.

For 1.4.5 and 1.5.20 and above, the file server will grant read locks
if the user has PRSFS_WRITE or PRSFS_INSERT.  (Insert only applies if
the user is the creator of the file).

This patch handles all of the above possibilities.  In the pre-1.4.2
case a read-lock request will be faked locally.


--- DELTA config for openafs-devel-1_5_x follows ---
DEVEL15-windows-dropbox-fix-20070426 openafs/src/WINNT/afsd/cm_access.c 1.7.2.14 1.7.2.15
DEVEL15-windows-dropbox-fix-20070426 openafs/src/WINNT/afsd/cm_vnodeops.c 1.69.2.28 1.69.2.29