Modifying the OS X Mavericks Authorization Database

Versions of OS X prior to Mavericks had a file located at /etc/authorization, which controlled the rights for many different actions, such as adding a printer, changing the time, or setting up Time Machine.  These rights were based on groups, and many admins modified this file so that users who were not admins could perform some of these privileged tasks.

After installing Mavericks, you will find that /etc/authorization no longer exists, and if upgrading the file will have been moved to /etc/authorization.deprecated, with any modifications no longer working.

Early in the developer previews, it was discovered that this file had “moved” to the /System/Library/Security/ folder.  This initial impression was only half correct, as it turns out that this is just the source file for the new authorization database.  The new database is located at /var/db/auth.db, and is a SQLite3 database.  This is what is actually checked by securityd for rights, and seems to be much faster than checking the old Property List format.

For those who would like to make modifications to the authorization database, the old methods of using PlistBuddy directly against /etc/authorization will no longer work.  Instead, there are three different methods which can work, though only one is Apple supported.

security command

Apple introduced the ‘security‘ command back in 10.5 – and it has supported the modification of the authorization database since then.  However, very few admins actually used this function due to lack of true documentation, and the fact that existing methods were relatively easy.  Even so, using this command is relatively easy.

For example, to allow everyone to modify energy saver settings, simply run this command as root, which will update the SQLite3 database.

security authorizationdb write system.preferences.energysaver authenticate-everyone

The result can be checked with the following command, which will give plist output:

security authorizationdb read system.preferences.energysaver

The security command can also take plist input, to enter rights which do not ship with OS X, such as the one to allow users to change the time zone, but not change the actual time.

Direct SQLite3 modification

Using the security command is an easy, appealing option for those who only need to set rights once, but if setting many rights or ensuring them, running the command many times many not be an appealing option.  Especially for those who use Puppet, direct use of the /var/db/auth.db database may be an appealing option.  In my limited testing, this has worked, but at this time it is probably not the best option.   As the SQLite3 database is simply a conversion of the Property List template, it is very straightforward.

The nuclear option

Of the three current options, this is certainly the worst, although it does work.  As /var/db/auth.db is created by securityd on boot from the /System/Library/Security/authorization.plist if it does not exist, an admin could modify the plist, remove the SQLite3 database, and reboot, at which time any changes would be picked up.  This might make it easier to adapt existing scripts, but please do not use this option.   It will wipe out any prior changes, and requires modifying /System, which an admin should never do.

Conclusion

For now, use the security command.  All existing scripts which target /etc/authorization will need to be rewritten, and the mac-authorization Puppet module does not currently work.  In the coming weeks, updates will make this much easier.

Much, much more to come on this subject, stay tuned!

Samuel Keeley

Samuel Keeley can frequently be found in ##osx-server on Freenode, or on Twitter @keeleysam.

More Posts - Website

Follow Me: