Authorization Rights and Mavericks

With the upgrade to Mac OS X 10.9, the /etc/authorization file has been renamed to /etc/authorization.deprecated. Typically deprecated means that the file is still being used but Apple is letting you know that this file will be dropped in some future update.

However, it appears the /etc/authorization.deprecated is no longer used; or at least not being updated as rights changes are made through the appropriate API.

Assorted tools hanging on the wall

With the old property list file deprecated, Apple have introduced a new /var/db/auth.db file. This file has the tell tale sign of being an sqlite3 file; with system confirmation files the .db extension almost always means sqlite.

It is easy to confirm the format using the file tool:

sudo file /var/db/auth.db
/var/db/auth.db: SQLite 3.x database

Using the sqlite3 tool we can look inside a copy of the new auth database:

sqlite3 auth.db.copy
sqlite> .tables
buttons         delegates_map   mechanisms_map  rules         
config          mechanisms      prompts

We can dump the schema and contents to bbedit as SQL:

sqlite3 auth.db.copy .dump | bbedit

The tables show what you might expect given the property list history. The rules table holds the most interest for those working with individual rights. Oddly, Apple’s engineers have chosen to mix rights and rules in this single table.

Working with Rights

Editing the property list file /etc/authorization was never easy but it was possible. It was also the only way to create certain classes of rights.

With Mavericks, administrators are put in the position of needing to modify rights without the support of their favourite text or property list editor. Now we are faced with a small database to manage.

During the process of building and supporting Power Manager, I wanted an easy tool for working with rights. We built these extra features into Power Manager and this was great but specialised to Power Manager’s needs.

authbuddy is the result of wanting a more generic tool. Using authbuddy you can get, set, and remove rights.

Silent Requirements

If you are working with rights using your own tools, there are subtle changes that Mavericks introduced.

If a code signed application creates a right, that right will silently included addition key value pairs based on the application’s code signature and identifier. The same application running pre-Mavericks does not create these values.

Let’s assume you have a code signed application called mysignedtool that creates a right. On Mac OS X 10.8 the created right would like something like:

Right 'uk.co.dssw.mysignedtool.sampleright' returns:
{
    class = rule;
    created = "404383740.720632";
    modified = "404383740.720632";
    rule =     (
        allow
    );
    version = 0;
}

On Mac OS X 10.9, the same application creates a very different right:

Right 'uk.co.dssw.mysignedtool.sampleright' returns:
{
    class = rule;
    created = "404317753.03233";
    identifier = "uk.co.dssw.mysignedtool";
    modified = "404317794.150556";
    requirement = "identifier \"uk.co.dssw.mysignedtool\" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = QZLG4JVSEE";
    rule =     (
        allow
    );
    version = 0;
}

Through a Developer Technical Support incident, I have confirmed these changes should not affect how your right is assessed. These values are being used to track what application created the initial right and not for what applications can use the right.