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

Question

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

Hi

I chacked my Systemlog, that was created over nicht. There are a lot of logs which i try to decrypt. The first on eis this one.

Oct 28 04:27:47 server kernel[0]: Sandbox: xcscredd(186) deny file-read-metadata /Users

Oct 28 04:27:47 --- last message repeated 16 times ---

Oct 28 04:27:47 server.mydomain.com sandboxd[71] ([186]): xcscredd(186) deny file-read-metadata /Users

Oct 28 04:27:49 --- last message repeated 7 times ---

It's comming every 13 minutes. I googled a little bit and find out, that xscertd is a certificate signing deamon.

The deamon config is located in /System/Library/LaunchDaemons/. It has a socket config, what means, that the service is started, when it is needed. As far as I know.

In /usr/share/sandbox/com.apple.xscertd.sb is no entry for the /User folder.

Should I enter a value like

(literal "/Users") in the allow file-read-metadata section?

Can someone tell me what the certificate signing deamon wants in the users folder?

And what activates every 13 minutes the certificate signing deamon which needs to read the file metadta in the users folder?

Mac mini, OS X Mavericks (10.9), Server Profile Manager Payloads

Posted on Oct 28, 2013 2:38 AM

Reply

Answer 1

Jan 14, 2014 3:07 AM in response to - Krzysztof -

Hi

I opened the suggested file but found that the suggested lines where allready in the file (at the end) yet I still get these messages in my logfile??

Reply

Answer 2

Jan 14, 2014 12:44 PM in response to - Krzysztof -

there is a step 5.

sudo killall xcscredd

to force xcscredd to launch with the new profile.

HTH

- Leland

Reply

Answer 3

Jan 14, 2014 12:47 PM in response to Leland Wallace

Hi

I realized that, but my point was that the suggested changes where allready present in the default file on my clean install. This suggests that, for my case anyway, my log messages are casued by something else.

My system is working fine but it really bothers me that the system.log is so "chatty". I guess I will have to live with it 😢

Anyway, thanks for taking the time to respond.

Reply

Answer 4

Jan 14, 2014 12:52 PM in response to Leland Wallace

Just checked my file again.. apparently my eyes doent work... this time it wasnt there. Going to give it a try 🙂

Reply

Answer 5

Jan 14, 2014 12:55 PM in response to consiglieri_swe

yes, that the entries were there already is odd, maybe you installed a seed for the next release? (which I hope will have a better profile). Not quite sure that question can be answered wrt the NDA though :-)

- Leland

Reply

Answer 6

Jan 14, 2014 1:14 PM in response to consiglieri_swe

Those lisp (Lots of Irritating Single Parentheses) inspired languages all seem to run together after a while.

- Leland

Reply

Answer 7

Jan 23, 2014 10:22 PM in response to - Krzysztof -

I'd also like to add my thanks. This certain works.🙂

Warwick

Hong Kong

Reply

Answer 8

Apr 30, 2014 3:40 AM in response to moritzz

For anyone having similar problems with xscertd spam, see this post for a fix: https://discussions.apple.com/thread/5974379?answerId=25629547022#25629547022

Thanks to the posters here for the breadcrumbs.

Reply

Answer 9

TopSteve

Level 1

69 points

May 8, 2014 12:27 AM in response to - Krzysztof -

- Krzysztof - wrote:

1. Open the terminal

2. type
sudo vim /Applications/Server.app/Contents/ServerRoot/System/Library/Sandbox/Profiles/xcscredd.sb
3. enter
(deny file-read*    (subpath "/Users")    (with no-log) )
into the file

To edit the file you have to press i.

4. The press ESC and then :wq (Enter)

But you shouldn't do things like this, if even don't know how to change a text file.

It's on your own risk.

My file reads

(deny file-read*

(subpath "/Library/Server/Xcode/Credentials/Data") ;; we have no buisness looking in here

(subpath "/Users")

(subpath "/var/_xcstest")

(subpath "/Volumes")

(with no-log)

)

But I still get the logs reached the limit of 500 lines in 3 secounds.

Reply

Answer 10

Oct 29, 2014 9:44 AM in response to TopSteve

Does anyone have any suggestions for determining the true cause of the log entries?

I could be wrong, but it appears that all the suggestions presented in this thread are aimed at disabling logging of the issue. This seems like the equivalent of disconnecting a "check engine light" on a car when it is lighting up.

In my case, I'm getting sporadic system freezes on a Mac Mini (i7, 2.3ghz, 4gb Ram, 10.9.5, Server 3.2.1), where the system just locks up - no response to input, file shares go offline, etc. When I view logs near the approximate system-lockup, I see boatloads of the xscertd -helper deny file-read-metadata entries referencing "/private/var/db/DetachedSignatures". I'm not sure if the log spamming is contributing to a crash. Is anyone else experiencing suspected crashes due to this, or is this just an annoyance in the logs to everyone else?

Reply