Upgrading to Golden Gate Beta 27.0 having BuildVersion 26A5388g removes entires already present in authorisation db files

We have a macOS application that adds entries to the Authorization Database (system.login.console) as part of its setup. We observed that after upgrading from macOS Tahoe to the macOS Golden Gate beta, the entries added by our application were removed, and the default system.login.console configuration was restored.

Is this expected behavior in the current Golden Gate beta, or is it a known issue? If it is a known issue, is there an expectation that it will be addressed in a future beta release?

Additionally, is there any recommended approach for preserving or restoring application-specific Authorization Database entries across major macOS upgrades?

It would be of great help if there is any suggested approach for the same.

Answered by DTS Engineer in 901265022

Ah, right, I misremembered. Sorry about that.

It’s not that the database is reset as a whole, but rather than specific rights got reset. At the time — and this was back in 2022 — the developer filed a bug about this (FB9986388) and that was returned as ‘behaves correctly’.

I went spelunking in Radar and found numerous similar bugs that were returned in the same way.

If I understand this properly, this is driven by the version property of each rule and right, for example:

% security authorizationdb read system.login.console | plutil -p -
…
{
  …
  "version" => 11
}

And you can see the code for this is Darwin.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We observed that after upgrading from macOS Tahoe to the macOS Golden Gate beta, the entries added by our application were removed

This doesn’t surprise me. My understanding is that this isn’t new behaviour. For a while now, major OS releases have reset the authorisation database. So, you’ll see the same behaviour if you update from macOS 15 to macOS 26.

is there any recommended approach for preserving or restoring application-specific Authorization Database entries across major macOS upgrades?

Not really. The best approach is gonna vary based on the target market for your product. For example:

  • If you’re targeting enterprise environments, which usually have strict control over the OS update process, you’d create documentation for site managers discussing this issue.
  • If you’re targeting normal Mac users, it would make sense to implement some sort of self-repair mechanism. But the exact approach you use for that is gonna depend on how your product is structured.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We had tried similar upgrades from Sequoia to Tahoe and we havent noticed any issues with the authorisation db. It was retaining any custom entries added to it during OS upgrade. Is this change a recent one due to which third party applications will be impacted?

Ah, right, I misremembered. Sorry about that.

It’s not that the database is reset as a whole, but rather than specific rights got reset. At the time — and this was back in 2022 — the developer filed a bug about this (FB9986388) and that was returned as ‘behaves correctly’.

I went spelunking in Radar and found numerous similar bugs that were returned in the same way.

If I understand this properly, this is driven by the version property of each rule and right, for example:

% security authorizationdb read system.login.console | plutil -p -
…
{
  …
  "version" => 11
}

And you can see the code for this is Darwin.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Upgrading to Golden Gate Beta 27.0 having BuildVersion 26A5388g removes entires already present in authorisation db files
 
 
Q