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...
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
