Created
September 22, 2013 16:46
-
-
Save loreb/6661739 to your computer and use it in GitHub Desktop.
Something I had never thought about, quoted from
http://micro.nicholaswilson.me.uk/post/33359696556/cute-little-thought-its-obvious-why-there-arent
[foreshortened, Nicholas Wilson] Methinks there should be an errno value for this...
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cute little thought: It’s obvious why there aren’t APIs for finding out, for example, the current credentials of the process on the other end of a UNIX-domain socket (there might be several processes on the end!) Less obviously, there could be no process on the other end: suppose you have a socket at your end, and the remote end is dup’ed into two related processes. You pass in an fd (with an SCM_RIGHTS message), then close it. It’s not open in your process, and it can’t be associated with either receiving process (either one of them could read it first). So, who ever’s on the other end of the passed fd is in the unusal situation of having a valid, connected socket with absolutely no process on the other end! Quirky. |
FreeBSD: LOCAL_PEERCRED, the manpage describes the same behavior
Solaris: not 100% clear, "A process that listens for connections retrieves the credentials of the peer at the time
the peer initiated the connection." but also "EINVAL The socket is connected but the peer credentials are unknown."? Sounds like it does the same anyway, but EINVAL leaves me with a 1% uncertainty
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Linux: SO_PEERCRED, returning e{uid,gid} of the process that called connect()