On 10/8/2014 2:23 PM, Todd Lewis wrote: > I'm looking for a tool or procedure that will look at ACLs in a > directory tree in AFS and suggest (possibly new) groups, memberships, > and permissions to help straighten out the mess that has grown there > over the years. > > We have an aging cell, and as projects have come and gone, we've > accumulated some rather ad hoc ACLs, some using groups, some not, some > with users who are no longer around... I try to discourage putting > individual users in ACLs in project group space, preferring instead use > groups in ACLs and put users in groups. But many times individuals were > added directly to one or more directory ACLs because it was easier at > the time. Some of these have become all but unmanageable. > > If anyone has suggestions for strategies or specific tools to facilitate > cleaning up small to medium sized nightmare forests of ACLs, I'd love to > hear about them.
Todd, I will answer the easy part of your question first. To remove stale access control entries from an ACL use fs cleanacl -path <path>+ That will remove entries for user and group numbers that no longer exist in the protection service. The rest of your question is hard and the answer is not going to be the same for any two organizations. When assisting organizations performing audits of the /afs file namespace after inappropriate access to PII, classified or otherwise proprietary data, the starting point is to audit the contents of the volumes to determine what policies need to apply to each. Once the organization is aware of what data is where and what policies should apply to it, then it becomes possible to determine: 1. if the volume boundaries are correct 2. if the ownership of each volume is correct 3. if the ACLs on each volume root is correct 4. if there are ACLs that are in violation of the applicable policy Automating consolidation of individual user access control entries into groups is fraught with peril. Its not that it cannot be done but unless the groups are created with the type of data the group is intended to protect in mind, it is very likely that an unsuspecting end user might extend group membership with the intention of sharing one particular directory but instead end up sharing other directories as well. As you are aware OpenAFS is file namespace with self-service access control assignment and group creation. As a result it is very difficult to enforce an access control policy on regions of the namespace for which volume ownership or administrative privileges have been granted to end users. As a result OpenAFS requires a trade-off between ease of use for end users and organizational control. It was for this reason that Your File System enhanced the access control and group models in Auristor (formerly YFS). Auristor permits organizations to define policies for portions of the name space that cannot be exceeded by end user grants. If a cell-wide scan is going to be performed, I advise against doing it through an AFS client and instead work directly against the volume. Performing a cell-wide scan as an administrator via an AFS client operates at network speeds will also modify the last access time for every volume which is often an unwanted side effect. If the last access time is useful, then it becomes possible to purge volumes from the tree due to lack of use. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
