> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jussi Laako > Sent: Thursday, October 10, 2013 7:36 AM > To: [email protected] > Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded > UID issue > > > 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.
Only if you look, and you still don't know if the other side broke the connection and is still running or if it died and there's a different process running with the same pid. > 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 Except that the original process could have close()d the socket and still be running, so the test in (3) yields a false negative. And, how do you do validate that "(1) is still intact"? > > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
