by AshamedCaptain | 2025-12-16 11:37:05+00:00
> I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths.

Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.

> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.

Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.

> hat even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.

I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.

I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is. You'd just put the data in the "more secure" storage to begin with.

What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.

You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?

> It would be ill-advised to have each application deal with how to encrypt user data.

Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).

> The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either.

In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.

> DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.

This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.

> you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.

I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.