Not at all. You call recvmsg and the getsocopt to get the SO_PEERCRED.
The “other” process exits. Another process gets created with the same
pid. You open /proc/PID/something. You get the wrong data. The mechanism
is 100% unreliable.
Except that you know that the other process has quit because the socket
got broken.
1) You get data from socket and issue getsockopt()
2) You read /proc/PID
3) You validate (2) by checking that the (1) is still intact and the
socket peer is still owned by the same PID
Even if it did fork() and exec() to pass the descriptor onward it
purposefully voluntarily did give it's own privileges to the child.
This use of stream sockets is generally bad and for this purpose there
should exist a datagram socket where each datagram will get security
context attached to it at the time of send and received as ancillary
data in recvmsg(). Or even better still, expand the more efficient POSIX
message queues (mq_open()/mq_send()/mq_receive()) to hold this information.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
