On 06/27/2009 12:15 PM, Jeffrey Altman wrote:
So yes, we have a problem. Using VFL_DFSFILESET is not going to provide a method of updating existing clients. The behavior for a large number of existing clients is going to be that the directory ACL takes precedence regardless of what per-file ACLs are set. As a result there is (as you describe) an information leakage problem. We do not have to worry about writes because those will be enforced by the file server. Its just reads on cached objects which have a more restrictive policy than that of the directory.I see two possible options when the client does not offer the "I support per-file ACLS capability": 1. if per-file ACLs are set on objects within a directory, the ACL reported by the old RPCs becomes the most restrictive ACL (which is going to be messy) 2. if per-file ACLs are set on object within a directory, the ACL reported by the old RPCs is empty thereby preventing access from clients that would leak the data. Any other ideas? Jeffrey Altman
First off I believe that clients determine the access rights based on the CallerAccess and AnonymousAccess fields in the FetchStatus structure, not on the actual ACL returned from FetchACL. So this type of change would affect all RPCs that return a FetchStatus structure, not just the new ACL RPCs. The file server would have to rely on more than the use of the new RPCs (ex: client capabilities) to determine how to evaluate the access rights.
These adjusted rights would also have to be enforced by other calls such as FetchData - but I think this relies on the same bits of code anyway.
1. means that granting additional access to a file (wrt the parent directory) through a file ACL would not work for old clients. That may be acceptable, but it depends on what people intend to do with the new facility. Of course if it's an issue they have the option to upgrade the clients. 2. seems too restrictive - setting any ACL on a file would make it unusable by old clients.
Both of these mean a user we can have different rights to a file depending on the client used - not great, but better than the cache leakage scenario.
Marc _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
