xcscredd(186) deny file-read-metadata /Users

did adding the metadata exclusion remove it from reporting in the log?

xscertd is another service entirely.

The real path is inside the Server.app bundle.

Server.app/Contents/ServerRoot/System/Library/Sandbox/Profiles/xcscredd.sb

file-read* should include the metadata as well (it's supposed to include file-read, file-read-data, file-read-metadata)

HTH

-Leland

xcscredd is needed by the daemon that handles the wiki service and others as well.

HTH

- Leland

Leland,

Would it be better to just give the service permission to access /Users? Is there a reason it is trying?

-Edric

From a "just get this working perspective" probably, but from a security perspective opening up permissions that you don't need is usually a bad idea. I mentioned one theory as to why xcscredd may be looking at /Users in an earlier post (I think its the keychain code responding to keychain notifications).

Its likely that once you allowed /Users it would ask for /Users/logged_in_user_name, etc... down to the login.keychain file. Its a slippery slope, and in the end, the most important data on most users computers is in their home folders under /Users.

steps up on the soapbox

Creating a good sandbox/seatbelt profile is hard. Not only do you have to deal with the file/resource acceses of your program, but also all the private accesses made by all the frameworks you are using. If you develop for the App store, the default sandbox profile is pretty complete, but there's still a risk that something may get by. Accesses that cause problems are usually caught in testing, but ones that are "benign" (e.g. not good from a security point of view, but not otherwise problematic) are harder to catch.

steps back down

HTH

- Leland

Adding

;; Added to prevent sandbox error's reported at https://discussions.apple.com/thread/5495141?answerId=23570570022#23570570022 (deny file-read-metadata    (subpath "/Users")    (with no-log) )

to

/Applications/Server.app/Contents/ServerRoot/System/Library/Sandbox/Profiles/xcscredd.sb

indeed got me rid of these log messages.

Thanks,

M.

I have the problem too, but I don't really not the steps to fix it. Could you tell me how to do it by step?

I had done it like you told me last day and it worked. Thx.

Hi

with 10.9 still the same error. I suppose it comes up everytime you have a new Server.app.

I have no users under /User. So it could be that there is seomthing hard coded in xcscredd.

Yours

Thanks for that. I am running a 10.9 and Server on a 2011 iMac. I am in the process of testing a deployment server for our College. I am attempting to build this up with DeployStudio and eventuall Reposado for deployment and update management for Macs we purchase for faculty and staff.

I restarted the machine and couldn't access my mouse because Bluetooth hadn't started. I attempted to bring up the Bluetooth settings with Alfred to check whether anything had changed. But no system preferences could be launched. I was otherwise able to launch a terminal and launch 'top' and launched 'Activity Monitor.'

In Top, process 'cma' just stayed up there and did not budge. This appears to be part of the McAfee 2.0 setup. (Yes, antivirus is our policy, even for Macs.) I turned off McAfee and restarted. On restart, even with McAfee back on everything was working, bluetooth and all.

On checking the console, I followed the xcscredd error codes through Google to here. I implemented this change in the xcscredd.sb per this hack. So far, so good.

Ð

Thanks a lot - Krzysztof - !!! it works for me too