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

Thu, 26 Apr 2007 14:06:44 EDT

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

Modified Files:
	cm_access.c cm_vnodeops.c 
Log Message:
DELTA windows-dropbox-fix-20070426
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 

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 

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 follows ---
windows-dropbox-fix-20070426 openafs/src/WINNT/afsd/cm_access.c 1.22 1.23
windows-dropbox-fix-20070426 openafs/src/WINNT/afsd/cm_vnodeops.c 1.98 1.99