The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #22830

macauthorization provider is broken on 10.9 (mavericks)

Added by Clay Caviness over 2 years ago. Updated over 2 years ago.

Status:UnreviewedStart date:
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version: Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:

This ticket is now tracked at:


In OS X 10.9, /etc/authorization has been “deprecated”; as of the GM, the update will move /etc/authorization to /etc/authorization.deprecated.

There is now /System/Library/Security/authorization.plist but it seems to just be the defaults; changing a right with the security authorizationdb command doesn’t change that file, but instead updates a sqlite db at /var/db/auth.db.

I did some quick testing, and just changing AuthDB in puppet/provider/macauthorization/macauthorization.rb isn’t enough because the provider reads the plist to determine current state, but in the 10.9 world the current state is reflected in the auth.db file (or the output of security authorizationdb commands) so even when a right change is applied, puppet doesn’t know.


#1 Updated by Gary Larizza over 2 years ago

So it sounds like we need to update the provider to interact with the Sqlite db in 10.9 – is that a plan, Clay? I don’t have 10.9 on anything yet, but I’ll pull it down when I get a no-travel week and see if I can’t play around with it. Thanks for reporting!

#2 Updated by Clay Caviness over 2 years ago

I think we’ll have to query the sqlite db to get the current state of things, and continue to use execs to security to create/modify rights. There still seems to be no mechanism to programatically create/modify rules, though; maybe these will have to be tweaked in the sqlite db? I haven’t tested that yet.

#3 Updated by Brian Warsing over 2 years ago


See this thread …

You won’t need execs of the security util to make this work:

sudo sqlite3 /var/db/auth.db ‘UPDATE rules SET “group”=“everyone” WHERE name=“system.preferences.datetime”;’ sudo sqlite3 /var/db/auth.db ‘UPDATE rules SET “group”=“everyone” WHERE name=“system.preferences”;’ sudo reboot

Should give the desired effect.

Extrapolating, (and I have not researched this) if there were Ruby gem available that could handle SQLite dbs, one could eschew exec statements altogether.

#4 Updated by Gary Larizza over 2 years ago

We have a Puppet feature that will check for the sqlite3 library —> You should be able to check for this feature and then react accordingly. I’ve not had to do any sqlite work in Ruby, so I can’t tell you if that library comes in core or the stdlib (I believe neither are true), but it appears to be popular with rails.

This would be worth some testing (direct sqlite3 interaction), but I’d assume it would be fine. Assuming testing goes well, we would just need a conditional check on the OS version < 10.9 to revert to legacy behavior, and anything 10.9 or greater to check for the sqlite3 feature. If the feature returns true, then interact with the DB directly, else fail with a message saying that the sqlite3 gem needs to be installed for the macauthorization provider to be used on OS X 10.9 or greater.

#5 Updated by Gary Larizza over 2 years ago

There’s also the activerecord gem with the sqlite3 adapter to solve this problem. We don’t necessarily have a feature for ‘active_record’ on its own – it’s covered in the rails feature (which is probably overkill for what we’re trying to do).

#6 Updated by Charlie Sharpsteen over 2 years ago

Redmine Issue #22830 has been migrated to JIRA:

Also available in: Atom PDF