10.14beta: find, chmod, rsync and more get Operation not permitted

A quick example:

% cd

% cd Library/Mail

% find . -name Junk.mbox -print

find: .: Operation not permitted

% ssh -x localhost '/usr/bin/find Library/Mail -name Junk.mbox -print'

Library/Mail/V6/9FC635B0-FCB5-4D1E-8FC0-7AB1FD4654ED/Junk.mbox

etc. etc.

This appears to be "broken as designed," as disabling SIP will reinstate root access to these folders. This is almost surely a security enhancement designed to prevent malware from getting access to personal data such as Mail, Contact Lists, etc (and though I haven't tested, I'd imagine Terminal is not the only app that's been locked out).

Nevertheless I would open a bug report anyway, as there needs to be a way for the administrator to selectively grant access to applications and utilties for backup and other purposes. Telling people the only suported way of backing up their own Mail folder is through Apple's built in time machine is flat out unacceptable IMHO....

By design. Mail is now protected (like other new locations). See the security session from yesterday for the full details.

I did file a bug-report.

Design or not... I feel that being able to use ssh as a workaround is kind of strange...

'root' on the machine (or launchd), or the user itself, accessing his/her own homedirectory, should have AT LEAST the same rights as the user that logs in from a remote machine...

This is bad. A simple utility like du(1) is unable to compute the space used by the Mail subdirectory.

Make the directory read-only is one thing. Make it unacessible is another. If Apple is bothered by unauthorized accesses, they should encrypt the data and make the directory read-only.

Open the Security and Privacy preferences, choose Privacy, Scroll to Application Data, unlock the preference, click '+' and add your terminal program. Restart the application.

Voila!

https://www.dropbox.com/s/v47fg3e618j2mkm/Screenshot%202018-06-07%2011.17.18.png?dl=0

Something is missing in beta 1 : normally, when you try to access, you should be granted with a dialog asking if you want to grant access, this does not happen...

Another example that I posted as well : you can access your users Library/Mail folder from the Finder, not from a shell !

Again, this is to me a limitation of beta 1, it really can not stay like this.

Look in Security/Privacy->Privacy tab and you will see sshd listed under "Data Access". User Data protection seems mainly about keeping "script kiddie" type malware from accessing sensitive data in your own home dir (which it would otherwise have access to since it normally runs under the same privs as the user that downloaded it). ssh has to be explicitly enabled by the user in the first place (this is where the "consent" is given), so the behavior does seem to make sense.

You can add Terminal.app to "Data Access" and your scripts will have access to these folders when they are run from within Terminal. System launchdaemons are a different kettle of fish. Likely "system administration" is what's needed here. This will presumably require a config profile or some facility similar to SKEL (hopefully with a less ****** UI) and/or MDM profile. Hopefully more documentation about this is forthcoming soon....

Thanks! I just added Terminal.app, which seems to work, but to be honest: The problems with the launchdaemon scripts is what worries me most.

In these scripts I have implemented the ssh-workaround for all failing commands, which seems to work well, but is a strange way of doing things.

stop

I also have the same problem, my installation package script needs to modify some user configuration, I want to complete the process automatically, without user intervention.

Adam, could you post the url of the bug you reported?

We are in a similar situation as david.chen. Our uninstall scripts need to access ~/Library/Application \Support/ but we are getting: Operation not permitted in Mojave beta.

The bug was filed under: https://bugreport.apple.com/web/?problemID=40883013

Don't know if you will be able to access that...

So far there has not been a response from Apple.

stop? Sorry?