Windows: Use AuthGroups for extent request error reporting
authorJeffrey Altman <jaltman@your-file-system.com>
Thu, 22 Dec 2011 02:17:33 +0000 (21:17 -0500)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Thu, 22 Dec 2011 15:10:32 +0000 (07:10 -0800)
commitb9ca435dcb5433218ecbb37ab41b85dabe0a5912
tree2b7d8eecbdca0dbfe938b70a9c64a916b30734d2
parent7e26dfd6dc893d14717aad411460fc781acc4001
Windows: Use AuthGroups for extent request error reporting

The afs redirector current tracks the most recent extent error
in the File Control Block.  Prior to this patchset the error
was returned to the requesting thread when the process Id matched
the most recent Process to issue a request.  This approach resulted
in a couple of problems.

 1. There are multiple threads that can issue an extent request
    on the same file at the same time representing different processes.
    Resetting the process Id with each new request could clear the
    error prior to its receipt.

 2. The failure may be due to inappropriate permissions.  Permissions
    are not associated with proceses but with Authentication Groups.

This patchset makes several changes:

 1. It enables the afsd_service to track the active authgroup as
    part of the cm_user_t structure and associates that object with
    the BIOD object to ensure that the active authgroup can be
    reported to the afs redirector.

 2. It modifies the AFSExtentFailureCB structure to include the
    AuthGroup GUID.

 3. It tracks the AuthGroup GUID associated with the extent
    failure in the non-paged file control block.

 4. It converts all tests on Process Id to use AuthGroup instead.

 5. It alters the behavior of error delivery such that reported
    error is only cleared after it has been reported once to a
    thread using the matching AuthGroup.

These changes make the situation better but not perfect as error
states can still be lost.  However, it avoids the case most often
seen in production where two processes (a end user process and an
anti-malware process) are fighting over a file and the anti-malware
process has no permission to access the file under its own credentials.

Change-Id: Ia5c3877b8d46de695c86884c4166dc812885a72c
Reviewed-on: http://gerrit.openafs.org/6396
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
12 files changed:
src/WINNT/afsd/cm_dcache.c
src/WINNT/afsd/cm_dcache.h
src/WINNT/afsd/cm_user.h
src/WINNT/afsrdr/common/AFSRedirCommonStructs.h
src/WINNT/afsrdr/common/AFSUserPrototypes.h
src/WINNT/afsrdr/common/AFSUserStructs.h
src/WINNT/afsrdr/kernel/lib/AFSExtentsSupport.cpp
src/WINNT/afsrdr/kernel/lib/AFSRead.cpp
src/WINNT/afsrdr/kernel/lib/AFSWrite.cpp
src/WINNT/afsrdr/kernel/lib/Include/AFSCommon.h
src/WINNT/afsrdr/user/RDRFunction.c
src/WINNT/afsrdr/user/RDRInit.cpp