[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Jussi Laako jussi.laako at linux.intel.com
Fri Oct 11 09:03:51 GMT 2013

On 10.10.2013 19:15, Schaufler, Casey wrote:
> 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.

For example in gsignond we have p2p socket for D-Bus, so in case the 
other end broke the connection, by doing so it also ceased to receive 
any services and all it's remote objects were destroyed.

If it's a different process under same PID, then the socket descriptor 
cannot be valid anymore.

> 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"?

If it did so, then we wouldn't perform any action for it either anymore. 
It can get the request done at phase (1) completed only by being around 
at (3) too, since it is anyway required in order to receive reply to the 
D-Bus message.

You get error if the socket's other end was terminated at least latest 
when you try to read() or write() to it. IMO, getsockopt(SO_PEERCRED) 
should also fail if the peer has closed the socket and terminated the 
process (I have not verified this yet though, but it is easy to do).

The way I implemented ACL in gSSO for standard Linux desktop (just DAC 
enabled, no MAC support) is that we have a p2p D-Bus over socket between 
client application and gsignond (works also with session&system bus). 
When request is received over the socket, SO_PEERCRED is used to fetch 
callers PID and then /proc/PID/exe symlink is dereferenced to binary 
path of the caller which is then compared against the ACL defined for 
stored credential and then response is performed and sent back over the 
same socket. So in case the application terminated meanwhile and the 
process got replaced with something else, the application wouldn't be 
able to receive the response it wanted. Or at least it had voluntarily 
given up it's privileges to someone else...
If someone has better ideas how to do it with D-Bus I'd be more than 
happy to hear about it!

--- 8< --- (maybe OT)
In these cases databases are also protected from the user, gsignond is 
running with setgid to "gsignond" group, but running with users' uid. 
Then databases are stored in a directory that is only accessible to 
uid=root gid=gsignond while per-user database is only accessible to 
uid=user gid=gsignond. User is not member of "gsignond" group. This way 
user cannot access the database directory, while gsignond cannot 
accidentally access databases of other users even if it had a bug...

More information about the Dev mailing list