It’s a really long-read post and I wast sure if it’s better to split it into three parts or put them together. On the one side, there are keyrings, from another – D-Bus, and finally, there is a Secret Service.
Eventually, I decided to keep them here together as I googled all it in the same scope and the are related to each other.
So, in this post we will speak about the next:
what is the keyring at all
what is the difference between the Linux keyring and GNOME keyring, and do they relate to each other
what keyring implementations are
what is the org.freedesktopSecret Service and how it relates to the GNOME keyring
what is D-Bus, and how we can use it to see how a keyring service is working
and a couple of examples with Linux Keyring, GNOME Keyring, KWallet, and KeePass as a keyring backend
This post is absolutely not kind of “tutorial” with “HowTo Configure it” but instead – just an overview of the components mentioned above to try to understand what they are and how they can be used.
A real example of how to configure KeePass and maybe GNOME Keyring will be added in the following posts.
This post was written by a long-long googling, so here will be a lot of links to documents and other materials that were used.
I may confuse something or even understood in a wrong way, so please welcome to the comments, if you’ll see any errors.
Now, let’s speak about the difference between the Linux kernel keyring and the GNOME Keyring: at first, I was confused as I suggested that GNOME Keyring somehow uses kernel’s keyrings facility, but now – it’s just different things.
The Secret Service API allows client applications to store secrets securely in a service running in the user’s login session.
Aha, i.e. Secret Service – it’s not some particular service or an application, but it’s a specification, kind of an RFC created by the GNOME and KDE projects to determine how this API must be realized for a client which wants to use GNOME Keyring or KWallet to store their secrets.
Also, the Secret Service API supported not only by the GNOME Keyring and KWallet but also for example by the KeePass and other applications.
IMHO, a bit confusing is the Secret Service name itself – “a hidden service”. If it would be called Secrets Service, i.e. “service of a secrets data” – it would be much more clear.
The Secret Service glossary
In short terms:
secret: a password itself, or any other secret data
item: each such a secret plus its set of attributes makes up an item
collection: a set of such items makes a collection (similar to the keyring or wallet concepts)
collections and items represented by D-Bus objects, each with its unique path
default collection: client applications without special conditions have to save items to the default collection which has to be accessible via the /org/freedesktop/secrets/aliases/default D-Bus path
Not its time to try to recall with is the D-Bus so often mentioned in the previous parts, and how to deal with it.
So, the D-Bus on of the Linux kernel IPC – Inter-Process Communication – mechanisms, allowing for separate processes inside of an operating system to communicate with each other.
messages: a base communication unit, data transfer similar to the TCP/IP, just in the D-Bus all data of a message is included to the message and not split over TCP-packets
when a message is sent usually it leads to some method to be called to execute some actions by an application providing this method
a message can be sent by an application to itself
namespaces and addresses:
as various applications can be placed on the same bus (or “listen to the same bus”) and during that the same application can provide various objects which can accept messages, then need to have some way to address those messages. In D-Bus, such an address consists of an interface name + service + an object name
a namespace example – org.freedesktop.dbus
an address example – unix:tmpdir=/tmp/my-app-name
interface: a set of methods and signals on a particular bus f a particular object. You can think of interfaces as named methods and signals group.
most of the interfaces will lead to the concrete construction of a language used for an application, for example, it can be a Java interface or a virtual class in С++
an interface example – org.freedesktop.Introspectable
service: represents a concrete connection of a particular application to a bus
under the service here means a bus name (in the origin – “well-known” Bus names), but keep in mind that the “bus name” here implies a particular connection name but not the bus name
if an application has more then one connection to a bus, or if the application is running in multitype instances – expanded by a PID number, for example, to make it unique
a service example – org.kde.screensaver
objects: the same application can provide access to its multiple objects using paths to separate those objects. Each such a path associated with a service represents a dedicated object, for example /MainInterface or /Documents/Doc1. Objects allow access to interfaces and the same object can provide such access to multiple interfaces at the same time