I would like to know what the ideal setting is to allow limited use of
this functionality to specific users.
You should be able to achieve this by changing the right specification in the authorisation database. Unfortunately the right specification format is not well documented. In situations like I usually poke around in the database to find a right that works the way I want my right to work, and then copy that.
Of course the next question is “How do I find the names of rights to copy?” AFAIK there’s no good way to do this — that is, no API and no specific tool to list all the known rights — but you can dump the database using sqlite3:
% sudo sqlite3 /var/db/auth.db
…
sqlite> select name from rules;
_mbsetupuser-nonshared
admin
allow
app-specific-admin
appserver-admin
appserver-user
authenticate
…
WARNING The location and format of this database has changed in the past (it used to be a simple property list) and it may well change again in the future. Use the above for for debugging and investigation purposes only. Do not encode information about its location and format into a product. If you do that, it’s very likely that your product will break in the future.
Additionally, is there a way to add more than one entry to the end of
the security authoriztiondb command? I noticed that the default set
is entitled and authenticate-admin, but I wasn't able to restore
it back to those defaults and could only set one at a time.
You’ve misunderstood how that command works. The read subcommand prints a property list representation of the right specification. The write subcommand accepts that same format. So this:
% security authorizationdb read right.name > right.name.plist
% sudo security authorizationdb write right.name < right.name.plist
is a no-op [1].
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Well, it probably changes the right’s mod date but I don’t think you’re concerned about that (-:
