asu/9000: Can't Clean Huge ACL database

[Michael Steele_2]

Hi Everyone: After using the regular mechanisms for pruning and shrinking the asu/9000 acl database ( acladm -P, acladm -S, acladm -U, and blobadm -qA )I am still left with a huge acl database of over 2,500,000 entries. This occurred after an NT Admin recursively wrote acls. How can I correct this? How can I get one inherent acl for the 49 subdirectories?

[Keith Lautenschlager]

Once explicit permissions have been added it's kinda tricky to get rid of them in mass, unless you just want to go back to the default acls. I guess the simplest answer would be to restore the acl file from a backup tape taken before the NT administrator set the explicit permissions. Assuming that's not a possibility, if you want to restore the default acl file you can simply stop ASU, make a backup of your current file:

mv /var/opt/asu/lanman/datafiles/acl /var/opt/asu/lanman/datafiles/acl.bak

And then start ASU, the default file will get created.

However, if you have these 49 subdirectories under a common top level directory, and you want them to inherit additional acl entries from that top level, it's more complex. What some customers have done is as follows:

- Stop ASU and make a backup copy of your acl file in case you do not get the desired results you can fallback to your original.

- Create a directory. This directory will temporarily take the place of the top level directory for your 49 subdirectories.

- Move the 49 subdirectories and their files under the newly created directory. (Not a bad idea to have a good backup before doing this)

- Create a new default acl file either by starting ASU or by using the acladm -N command.

- Set the permissions on the original top level directory that contained the 49 subdirectories the way you want them to be, and how you want them to be carried down through the 49 subdirectories via inheritance.

- Now copy the 49 subdirectories back under their original top level directory. In doing so they should 'inherit" the permissions of their parent directory, which gives them a pointer, and not an explicit ACE in the ACL file. This should give you the permissions you desire without growing the acl file.

Again, I would strongly suggest you make a backup copy of your acl file, with ASU down, and of the directories/files in question, so that if anything goes badly you can always recover to the state that you are in now.
If you have a support contract with HP you may want to open a case and talk to the Response Center to get clarification and details on this procedure.

[Michael Steele_2]

Thank-you. That's very useful.

Backups are a dead end since my client keeps only a months worth of tapes, and the problem was discovered after a month of time had passed.

Regarding: "- Set the permissions on the original top level directory that contained the 49 subdirectories the way you want them to be, and how you want them to be carried down through the 49 subdirectories via inheritance. "

I've been given the assignment of running "net perms" on each file below each of the 49 sub dirs in order to determine the default top level permissions to be used for inheritance.

This seems a waste. Certainly its inefficient and time consuming. Are there alternatives?

I'm also collecting the files that fail "net perms". One pattern I'm seeing is the folloing: "Tom Thumb". Where a space appears in the file name. How should these be dealt with?

Thanks in advance.

[Keith Lautenschlager · Accepted solution]

First the easy part, if you have a file or directory name that contains a space you must enclose it in quotation marks. For example, if you had a file named tom thumb in the root directory, the command to display the permissions would be:

net perms c:/"tom thumb"

This is true for most of the ASU commands that point to a file with a space in the filename, enclose it within quotation marks and you should be able to perform the action on it.

There is not much I can say about going through each subdirectory to see how they are currently set, and then applying that to the top level to be inherited, without knowing much more about the usage of the files/dirs and the security implications involved. It would depend on if there are subdirectories within the 49 that some users will need access to, but others will be exluded from. If that's the case you will need a mix of both inherited permissions, and then explicit permissions. Inherited permissions are going to effect each file and subdirectory equally, so once set you would have to go through and either add groups/users, or take away groups/users, depending on who should and shouldn't be allowed access. Once you start adding explicit entries, and carrying them down through the subdirectories, that is when the acl file begins to grow.

If you have any specific questions please post them and I will try to answer them. Otherwise, without more details, I can't really give you a good answer on viewing the permissions to be used to set the top level.