]> git.michaelhowe.org Git - packages/o/openafs.git/commit
DEVEL15-windows-dropbox-fix-20070426
authorAsanka Herath <asanka@secure-endpoints.com>
Thu, 26 Apr 2007 19:08:00 +0000 (19:08 +0000)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Thu, 26 Apr 2007 19:08:00 +0000 (19:08 +0000)
commita14a06945e05bd9ca8a2ae68312e85d8d09ae2ce
tree9f33809f6b8b98f2ce18b56e50cd7ced3e29afef
parent767daed0b8930fcb8a4af6513397f1857d087021
DEVEL15-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.

(cherry picked from commit bfed93d7fce113690c20e1cad102c8b23c0aa17f)
src/WINNT/afsd/cm_access.c
src/WINNT/afsd/cm_vnodeops.c