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

Feb 14, 2017 11:45 AM in response to adrianmartini

This is an old thread, but I have come across this problem with more concern than just my log filling up. This is actually affecting/preventing operation.
For me, I was looking into why the "Autoimporter" was no longer able to transfer my iPhone pictures into the requested folder and discovered these messages appearing when I connect my phone. So it appears this security feature is preventing an important operation for me. Blocking them from the log seems to be a naive solution - head in the sand. Those who did this might have tough time figuring out the problem when they later find the operation that isn't succeeding and was generating the errors.

So, I second the suggestion to determine the root cause.

Reply

Answer 2

Oct 28, 2013 3:01 AM in response to - Krzysztof -

And something like

(literal "/Users")

(regex #"^/Users/\.*")

in the allow file read* section?

Reply

Answer 3

Oct 28, 2013 3:39 AM in response to - Krzysztof -

im having the same issue.

Reply

Answer 4

Oct 28, 2013 8:51 AM in response to ebolaseph

+1

Reply

Answer 5

cpragman

Level 2

465 points

Oct 28, 2013 10:04 AM in response to - Krzysztof -

Me too

Reply

Answer 6

Oct 28, 2013 1:55 PM in response to - Krzysztof -

xcscredd is part of the Xcode Server service, it holds the credentials for logging into repositories, it has a very restrictive sandbox.

That message is likely a result of the security apis dealing with keychain notifications. It is benign and should have been dealt with in the sandbox file with a no-log directive.

It really is nothing to worry about.

HTH

Leland

Reply

Answer 7

Oct 28, 2013 2:08 PM in response to Leland Wallace

I thought it was a permission problem with something xcscredd is trying to access. Anyone have any further info on this topic?

Also, if this is just a benign log message, is there any way to dissable the log output?

Reply

Answer 8

Oct 28, 2013 2:28 PM in response to ebolaseph

You should be able to remove that log message by editing the sandbox profile for xcscredd.

add something like:

(deny file-read*

(subpath "/Users")

(with no-log)

)

HTH

-Leland

Reply

Answer 9

Oct 28, 2013 2:33 PM in response to Leland Wallace

Yes but why do a server service, which is running in the background read rights for the user folder?

What important can be inside it?

Reply

Answer 10

Oct 28, 2013 2:44 PM in response to - Krzysztof -

It is my understanding that the portion of the security framework that implements the keychain APIs gets notifications from securityd every time a keychain operation happens on the system. That code (in the clients adddress space) has to verify the keychain path to see if it is a path that the client is interested in. The default application sandbox allows this. Since xcscredd is a deamon process, with no need to look into user folders, it does not use the default application sandbox, and thus is seeing (and denying) the verification attempts.

It's worth filing a bug against Server to have them fix the log issue.

HTH

- Leland

Reply

Answer 11

Oct 28, 2013 2:54 PM in response to Leland Wallace

Thanks for the anwsers. I will try it with the sandbox entry and write here tomorrow about it.

And I will make a bug report.

An other question. You seem to know s little bit about the processes.

I have an other log problem here. It spams everytime I open the Keychain.

https://discussions.apple.com/thread/5490121

Can you tell me what secd is?

Reply

Answer 12

Oct 28, 2013 3:40 PM in response to Leland Wallace

I changed the sb file but the logs are still there.

Do I need to restart?

Reply

Answer 13

Oct 28, 2013 3:42 PM in response to - Krzysztof -

you could reboot, or you could just kill xscredd

sudo killall xcscredd

HTH

Leland

Reply

Answer 14

Oct 28, 2013 6:17 PM in response to - Krzysztof -

Which sb file? Could you post the filepath? Also, let me know if this stops the error logging. I hope to fix this on my server tonight. Thanks

Reply

Answer 15

Oct 29, 2013 12:26 AM in response to ebolaseph

It's the

/usr/share/sandbox/ com.apple.xscertd.sb

file.

Now I checked the log. Over night i rebooted and didn't log in.

So there haven't been any logs from xscertd.

But now I logged in an see, that they are commin again.

kernel[0]: Sandbox: xcscredd(186) deny file-read-metadata /Users

But I it's only the metadata. I think that it is needed to change

(deny file-read*

(subpath "/Users")

(with no-log)

)

to

(deny file-read-metadata

(subpath "/Users")

(with no-log)

)

or just add the last one additionally.

Will try this out and tell you the result here.

Reply