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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
