Linux: split GNOME Keyring integration into a separate process.
This will avoid possible deadlocks with password sync by removing any need to
access the UI thread (aka the GLib main thread, required by GNOME Keyring).
Even with this change, the sync team needs to remove calls to private blocking
password store methods so that we can remove those methods and avoid blocking
the DB thread for slow GNOME Keyring operations. (We can then move GNOME
Keyring access back in process if we want.)
Basic theory of operation:
NativeBackendGnome creates a KeyringProxyClient, which forks and executes
chrome-keyring-proxy (a small helper binary). Then NativeBackendGnome creates
a RequestContext for each RPC it wants to run, and calls a proxy client method
that returns immediately but saves a pointer to the request context. Inside the
request context is a WaitableEvent that will be signaled when the request is
complete and the reply has been stored in the request context. (This design is
necessary because NativeBackendGnome implements a synchronous API, but we want
to allow parallel requests to be made.)
The proxy client assigns each request an ID and marshalls it into a set of
lines terminated by a blank line to send over over a socket to the keyring
proxy, which unmarshalls the request and calls the appropriate GNOME Keyring
APIs. The reply is sent back identified by the request ID, and a refcounted
file descriptor watcher delegate sees the readable file descriptor on the file
thread and handles the data, possibly signalling a waitable event if the data
completes the reply to a pending request.
The chrome-keyring-proxy binary is very small and does not depend on any chrome
libraries like base, net, etc. Further, the protocol is human readable which
may be useful for debugging. These were both intentional choices that ruled out
any of the other IPC mechanisms that might have also worked.
Total comments: 3
Total comments: 15
Total messages: 4