Follow-up for #3326 #3397
Follow-up for #3326 #3397
Conversation
Now that #3326 landed I think it might be less confusing to keep using the --nodbus wording. Couldn't come up with a better alternative (yet), so this might need future improvements.
| @@ -40,5 +39,9 @@ disable-mnt | |||
| ?BROWSER_DISABLE_U2F: private-dev | |||
| # private-tmp - problems with multiple browser sessions | |||
|
|
|||
| # prevents access to passwords saved in GNOME Keyring and KWallet, also breaks Gnome connector | |||
| # dbus-user none | |||
| # dbus-system none | |||
There was a problem hiding this comment.
Can we block the system-bus?
There was a problem hiding this comment.
@rusty-snake Not sure, I'm actually not that familiar with chrome-based browsers. So if you say the system bus can be blocked without users being unable to save passwords etc. I'm totally ok with that. Thanks for the input, I didn't want to commit this without seeking some advice.
There was a problem hiding this comment.
Password are per user, therefore on the session-bus.
In general: I block the system-bus in my pre-globals.local for around two month now, and only allowed it for d-feet and searhorse. IHMO we can add dbus-system none to the most profiles.
There was a problem hiding this comment.
But I'm not sure if it maybe still breaks something in chromium.
There was a problem hiding this comment.
@rusty-snake That makes sense, thanks for your input, as always. I've blocked the system bus, we can change this later if we get issue reports.
Blocking the system bus shouldn't affect password functionality etc, as that uses the session bus.
Purely cosmetic stuff, no functional changes.