Re: Remote pid with SOCK_DGRAM local socket

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>> [I]t seems to me [sending PID] should be part of SCM_CREDS.
>>> What if more than one process has an open fd to the socket?  Which
>>> should it give?
>> The one which did the send, of course.
> There is, of course, a race condition, since that one could exit
> quickly.

That race condition exists for any method of passing PID information.
Even if you prevent the process from doing final teardown while the
data is in the socket buffer, it can still disappear between the time
the value arrives in userland memory and the time userland does
anything with it.  The only way I can see to stop that is to pass not a
PID value but some kind of capability handle which prevents process
teardown until it (the handle) is destroyed.  (This would probably be a
file descriptor of some sort.  AF_PROC, anyone? :)

>> You have exactly the same issue for the information SCM_CREDS
>> already carries; a quick look at the code makes me think the issue
>> is resolved this way already for that data.
> The PR spoke of bind() and connect()...

As far as I can tell from looking at 39108, it is basically doing
exactly what I was talking about except that it has a separate SCM_*
data blob for the extended information, rather than versioning the
existing *_CREDS stuff.

In particular, I can't see any reason it doesn't have the race you're
concerned about.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B