Obstacles for kdbus

Posted Apr 18, 2015 18:44 UTC (Sat) by nybble41 (subscriber, #55106)
In reply to: Obstacles for kdbus by mathstuf
Parent article: Obstacles for kdbus

> ... I'm locking it down so that access is based on a per-application basis.... Determining the binary is dependent on the executable pointed to by /process/PID/exe.

Unless you're doing something to prevent LD_PRELOAD and ptrace(), I'm not sure what you intend to accomplish by this. Even ignoring any potential PID race conditions, the code which is running and has access to the message bus is not determined solely by /proc/PID/exe.

Obstacles for kdbus

Posted Apr 18, 2015 19:11 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Currently, kwallet and gnome-keyring have a single "unlock" state at the collection level (though ISTR kwallet also gating based on the app, access was still global once permitted). Once, say, Firefox unlocks the store, any app can go in and query passwords. To me, it doesn't make sense to allow Firefox access to passwords intended for Pidgin or git, and vice versa (and they can even delete each other's passwords). As for the actual code running, yeah, something better would be nice, but it's more to minimize leaking if an application does have problems. It's already a pain to migrate dozens of accounts to a password store in the first place and I don't want to imagine trying to get back once malware starts targeting password stores (either by quietly siphoning, deleting, or modifying passwords in them) through the apps which communicate with them.