[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Jarkko Sakkinen jarkko.sakkinen at intel.com
Thu Oct 10 05:31:27 GMT 2013


On Wed, 9 Oct 2013, Dominig ar Foll (Intel OTC) wrote:

> If 'SO_PREECRED is fine', the pid that we will be read is the correct pid of the caller.
> Then it seems that your "unless" clause will be validated and /proc/PID should be OK.

I have doubts whether SO_PEERCRED is fine or not (and I didn't see
reasoning to back that up either).

I'm certain we found at least SO_PEERSEC to be racy in Harmattan
but I don't have a test case at the moment to prove that. I'm not
100% sure about SO_PEERCRED just because I cannot recall whether
tests run then only proved the race condition to exist with
SO_PEERSEC or both SO_PEERCRED and SO_PEERSEC.

Conclusion then was that only using SO_PASSCRED and SCM_CREDENTIALS
is non-racy way to authenticate communication with UDS sockets.

PID is racy. How could you ever count on it? Process can cease to
exist right after getsockopt(). inode numbers are also only 32-bit
for procfs so other procfs file can get the same inode numer under
hazardous circumtances.

/Jarkko


More information about the Dev mailing list