Full Disk Access rights during migration from Monterey to Ventura beta 11

Hello,

when FDA rights are given in macOS Monterey, the TCC entry reflects this and the process using ES Client works as expected.

entry as follows: kTCCServiceSystemPolicyAllFiles|com.sophos.endpoint.scanextension|...

after migrating the OS to Ventura beta 11 with the ES Client using process installed, the TCC entries read as follows:

kTCCServiceSystemPolicyAllFiles|com.sophos.endpoint.scanextension|... kTCCServiceEndpointSecurityClient|com.sophos.endpoint.scanextension|...

The old entry is still present, causing our software to report that the precondition of FDA is still valid. But internally the ES Client will report an error when being created, since the newly introduced entry does not reflect the FDA permissions granted.

It can be manually solved by removing the executable from the FDA list in System preferences and re-adding it but this is not the ideal solution.

Is this a know problem?

Frank Fenn

Sophos Inc.

Post not yet marked as solved Up vote post of frankfenn Down vote post of frankfenn
2.2k views
Posted by
frankfenn
Reply
Add a Comment

Replies

Is this a know problem?

It will be once you file a bug about it (-:

Seriously though, either the macOS engineering teams knows about this or they don’t. If they know about it, your bug will be closed as a dup. If they don’t, your bug will drive the fix. Either way, you’ll receive status updates. So it’s a win all round.

Please post your bug number, just for the record.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

FB11689760

Posted by
frankfenn
Up vote reply of frankfenn Down vote reply of frankfenn
Add a Comment

This issue is still occurring on the RC version in our testing. It seems to affect Microsoft Defender and other security provider solutions when upgrading from Monterey to Ventura. We've seen no movement on the feedback. Is this something we can expect to be fixed for GA on Monday?

Thanks,

Trace

Posted by
DeveloperTrace
Up vote reply of DeveloperTrace Down vote reply of DeveloperTrace
Add a Comment

This issue is still occurring on the RC version in our testing.

Yeah, that gels with my experience. I’ve seen a bunch of reports about problems like this (r. 101111364) but I’ve no concrete info to share.

We've seen no movement on the feedback.

What was your bug number?

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Hi eskimo,

FB ID is FB11689760

Posted by
DeveloperTrace
Up vote reply of DeveloperTrace Down vote reply of DeveloperTrace
Add a Comment

Thanks for the (many!) bug reports we’ve received about this issue. Unfortunately I don’t have any news to share right now. This is definitely a bug. We hope to fix it sooner rather than later but, as always, I can’t discuss The Future™.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

We hope to fix it sooner rather than later

This bug is reported as fixed in macOS 13.1 beta. See (r. 100857507) in the release notes.

I believe it’s also fixed in 13.0.1 but I haven’t found a place where we say that officially and I haven’t had a chance to test it for myself. If anyone else has direct experience with this, please post it here.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Quinn,

We're trying to minimize updates chasing the key name.

The only OS version with the kTCCServiceEndpointSecurityClient key is 13.0.0? All others will use kTCCServiceSystemPolicyAllFiles?

Is that correct -- at least for the near future?

Thanks a lot, Jim

Posted by
joconnor
Up vote reply of joconnor Down vote reply of joconnor
Add a Comment

Is that correct -- at least for the near future?

You are asking about implementation details that I’ve never dug into. My advice is that you test the user-level scenario, not rely on your understanding of the implementation.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

This bug is reported as fixed in macOS 13.1 beta. See (r. 100857507) in the release notes.

I've been following this and hoped 13.1 would address this, as I think I'm running into it.

I upgraded a Macmini9,1 to macOS 13.1 today, and made a macOS 13.1 USB installer using softwareupdate --fetch-full-installer --full-installer-version 13.1

I have a set of software permissions under Full Disk Access and other System Settings configurations (such as TeamViewer Host permissions to function).

I then took a second Macmini9,1, erased the Volume, installed 13.1 using the installer, activated, and did an install from the USB. During setup, I migrated from a drive created with Carbon Copy Cloner that is a valid Migration source. Everything transfers except the settings under Privacy & Settings, the TeamViewer permissions are unset, and nothing is listed under Full Disk Access.

Curious if there is something I'm overlooking, if there are any alternative ways to migrate this information, or if the official line is this is not possible. I'm also open to the concept that this can be fixed by imaging app behavior changes due to 13.1 work, say if Carbon Copy Clone or SuperDuper! need to adjust the values they use.

For now I'm going to have to write documentation to have techs manually set up Full Disk Access for the required operation of the systems...

Posted by
APB Development
Up vote reply of APB Development Down vote reply of APB Development
Add a Comment