Designing ACLs

Using shorter ACLs with general identifiers has several advantages. The operating system processes shorter ACLs more rapidly. In addition, when employees change but the functions remain the same, you do not have to change every ACL across the system. Instead, you change the holders of the identifier. If employees leave the project, you can edit their records in RIGHTSLIST.DAT so they no longer hold the identifier, or if they leave the company, you can remove their user authorization file (UAF) records altogether. When new employees are hired for the same jobs, grant the new users the right to hold the identifier. The new users then have the same ACL-based access as the former users.

Your overall design should consider the types of files and other objects on your system and the protection needs of each. If you have successfully designated groups and identifiers, you should be able to easily design ACLs and define standard protection. Time spent clarifying the common access needs of your users simplifies the design of identifiers and ACLs. You will also simplify the job for your users who place ACLs on their files.

Do not use ACLs indiscriminately. They consume paged system dynamic memory when files are open. They also require additional processing time. ACLs are best applied where protection is really needed. If your ACLs become too long (for example, more than 200 entries or so), you might consider grouping users into discrete categories and creating general identifiers.

At the same time, do not create excessive numbers of identifiers. In particular, do not grant too many identifiers to one user. Having a user hold more than 10 or 20 identifiers may result in excessive time spent processing ACLs. If you find an individual holding too many identifiers, you may want to reconsider how your groups are structured. Or, if this is an exception case, consider putting the individual directly on the necessary ACLs.