windows-dropbox-fix-20070426
authorAsanka Herath <asanka@secure-endpoints.com>
Thu, 26 Apr 2007 19:06:44 +0000 (19:06 +0000)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Thu, 26 Apr 2007 19:06:44 +0000 (19:06 +0000)
commitbfed93d7fce113690c20e1cad102c8b23c0aa17f
tree0c02d43e30deca931938a33f28cd604e9a420cb6
parent92ecfdd675e8a851c7f0f19e5359362fa00c1c8f
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
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.
src/WINNT/afsd/cm_access.c
src/WINNT/afsd/cm_vnodeops.c