[PUP-661] Remove broken macauthorization provider from core types Created: 2013/11/05  Updated: 2018/07/03  Resolved: 2018/07/03

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: PUP 6.0.0

Type: Bug Priority: Normal
Reporter: redmine.exporter Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: breaking, macos, redmine, removal, type_and_provider
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates PUP-8850 Remove type/provider code from puppet Resolved
Relates
relates to PUP-8573 Extract macdslocal type/provider into... Closed
Template:
Epic Link: Puppet 6.0.0 Removals
Team: Platform OS
CS Priority: Reviewed

 Description   

Update 12/22: Based on comments from Allister and Nigel this should be removed from core types. That may need to wait until Puppet 5 for semver reasons.

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.



 Comments   
Comment by Gary Larizza [ 2013/12/20 ]

Can you guys give this a shot --> https://github.com/glarizza/puppet-authorization

I'm thinking it's probably better to eventually rip these types out of core so we can work on them much faster than tying them to Puppet releases

Comment by Eric Sorenson [ 2014/02/25 ]

Good summary of the issues here: http://www.afp548.com/2013/10/22/modifying-the-os-x-mavericks-authorization-database/

Comment by Nigel Kersten [ 2014/09/22 ]

Gary Larizza have you worked on this much lately? We're looking at sorting this out at the contributor summit.

Do you think it's critical to switch to to two types? I'd quite like to keep backwards compatibility on the interface, and add 10.9 support to the existing base.... and two types breaks that.

(this is all with the goal of pulling things out of core)

Comment by Gary Larizza [ 2014/09/22 ]

I really haven't, no. There was a reason I split them out, but it's been so long I forgot. Honestly I just coded it up to see if it would work, so I'm open to other designs.

Comment by Allister Banks [ 2015/12/17 ]

In lieu of this actually being worked as a ticket, please remove the code from puppet core types.

Comment by Nigel Kersten [ 2015/12/21 ]

Allister Banks or anyone, have you looked at Gary's code?

I concur this should get pulled out, it's clear no-one is actually relying upon it given the level of feedback and issues.

Comment by Allister Banks [ 2015/12/21 ]

Gary's module was suggested to me by Sam Keeley, so I'll give this a spin as soon as possible. security interactions were supposedly compatible back to 10.8, but since official support starts at 10.9 anyway it's fine to just look forward to a community module.

Comment by Nigel Kersten [ 2015/12/22 ]

given that this has never been a solid public API when interacting via the command line and plist twiddling, it's a good candidate to pull out of core and into a module regardless of whether it gets fixed or not.

Comment by Eric Sorenson [ 2016/09/13 ]

Assigning to Agent & platform for Mac OS X work.

Comment by Branan Riley [ 2018/05/09 ]

I'd propose we remove this in Puppet 6, with the possibility of building a new module (possibly based on Gary's work) that we can eventually support and possibly vendor into the agent.

Comment by Nigel Kersten [ 2018/05/09 ]

Given how long this has been broken, my vote would be to just remove it and not even wait for 6 - I think we've been overly concerned with semver wrt this specific issue. I'm not the deciding vote there though.

There's nowhere near enough demand from the user base to invest effort in replacing it. That shouldn't be a consideration.

(For those who don't have the context, I wrote this originally, and in the years since Apple broke it with an OS update, I've shepherded almost all the users onto other solutions)

Comment by Branan Riley [ 2018/05/09 ]

Unless we want to rip it out in a Z release, puppet 6 is the next release vehicle. I agree there's no reason to leave it around (since it's broken), but it's not like we're gonna sit on this for years or anything

Comment by Josh Cooper [ 2018/07/03 ]

Duplicate of PUP-8850. This is being done as part of a larger effort to extract computer, mcx and macauthorization out of puppet and into a module.

Generated at Fri Dec 13 09:00:44 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.