A defect fix made to the AFS 3.3a cache manager introduced a small incompatibility with AFS 3.3 and earlier fileservers. The problem manifests itself as "Permission denied" errors for directories that should be accessible based on IP address ACL entries. The problem only occurs under very specific conditions (described below), so most sites will not experience it. Those users who get the "Permission denied" message could work around the problem by waiting for the status cache entry to be flushed (up to 4.5 hours) or by issuing "fs flushvolume <dir>" for the affected directory. The permanent solution is to upgrade the fileserver housing the IP-based ACLs to AFS 3.3a. (Downgrading the cache manager to AFS 3.3 or earlier will also prevent the problem, but is discouraged by Transarc Product Support since many defect fixes were made to the cache manager in AFS 3.3a.) The specific conditions that lead to the inappropriate error are detailed in the list below. All five of the conditions must be present in order for the problem to surface. - Running the AFS 3.3a or later cache manager. - Accessing files stored on an AFS 3.3 or earlier fileserver. This includes version 3.3, 3.2b, etc. - The user has no tokens for the cell housing the directory. This is most likely to happen when the directory is in a foreign cell or when the process is unauthenticated. - The ACL grants certain access to a group containing an IP address entry and that access is not also granted to system:anyuser. For example, the ACL might have been set with the entries "transarc:localnet read" and "system:anyuser none". - The status information for the directory has already been cached on this client from a different PAG. (This is where it gets tricky.) Basically, another user must have successfully read the file from the same client within the last four hours. The resulting effect is as follows: - The first user who tries to read the directory will get the appropriate access rights. More exactly, any process in the same PAG as the first one to obtain status info for the directory will get normal rights. - Users not in the same PAG who aren't authenticated in the cell get only the access granted to system:anyuser, thus ignoring any groups which may contain relevant IP address entries. - Once the status information is flushed from the cache, the directory will again be readable to the next user who accesses it. Note that the status cache is independent of the data cache and has different rules for when it is flushed. The information will be cached for a maximum of 4.5 hours. Issuing the command "fs flushvolume <dir>" will immediately flush the cache. If you need further information concerning this problem, please contact Product Support through the normal channels. Joe Jackson, AFS Product Engineer, Transarc Corp.
