https://bugs.kde.org/show_bug.cgi?id=501030
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from [email protected] --- The dbus methods and the SQLite WAL seem like the most concerning problems, because they can't be feasibly worked around: $KLIPPER_DATABASE can be set to tmpfs, but as long as the WAL is a regular file and remains opened, it can be trivially read (even if unlinked) by any process (of the user running Plasma), same for dbus. As mentioned in the previous comment, text data is retained in the WAL long after the clipboard history has been cleared. Could we perhaps get a separate environment variable for the SQLite db, e.g. KLIPPER_SQLITE_DB? SQLite itself and QSqlDatabase::setDatabaseName() allow setting a special name of ":memory:" for a memory-only db. It could be set to ":memory:" automatically when KeepClipboardContents == false (and KLIPPER_DATABASE could be set to an mkstemp() dir in /tmp). Currently, KLIPPER_DATABASE can't be set to a non-path value, because the path to ${KLIPPER_DATABASE}/data/ is derived from it. As for allowing dumping the clipboard contents via dbus, it could be gated behind a boolean in klipperrc. There's already a precedent: an entry with the x-kde-passwordManagerHint hack can't be read via dbus methods. > Is it actually possible to disable Klipper at this point instead of just > hiding relevant user interfaces? It's possible to disable klipper ("System Tray Settings -> Clipboard -> Never show (disabled)"). It's really disabled with that setting (as in: no further writes to ${KLIPPER_DATABASE}/{data,history3.sqlite{,-wal,-shm}}). Apart from losing klipper's features, copied data is lost when the source application quits, but even with klipper running, that's also true for text data using the "x-kde-passwordManagerHint=secret" hack and by default for non-text data (the latter because the default is "IgnoreImages=true" in klipperrc, aka. "General -> Non-text selection -> Never save in history" in klipper settings). BTW: looks like if something's not saved to history, it also means it's not saved to the SQLite db and the "data" dir, and not readable via dbus - see https://invent.kde.org/plasma/plasma-workspace/-/blob/3eea15a66d35bde06368115061d5ce92e4ca00b1/klipper/historymodel.cpp#L892 > The clipboard history can also be accessed through AT-SPI and the D-Bus > interface, > so if users really care about their privacy, they should disable the > clipboard widget. I don't think it's just vague "privacy" concerns (valid as they are), because it's a vector for effortless credential exfil (and any confidential data as well). "x-kde-passwordManagerHint" is far from being consistently used by apps and it does nothing for e.g. text copied from konsole. AFAICS moving to a completely in-memory model would be non-trivial, as klipper's history heavily relies on the ${KLIPPER_DATABASE}/data/ dir, but disabling the on-disk WAL and the dbus methods should be much easier? As for workarounds, there aren't any good ones. This really needs to be fixed in the code. That said, klipper can at the very least be prevented from leaking data to permanent storage by: - setting the KLIPPER_DATABASE environment variable to a path on a tmpfs filesystem mounted with the "noswap" option. See: https://invent.kde.org/plasma/plasma-workspace/-/blob/3eea15a66d35bde06368115061d5ce92e4ca00b1/klipper/historymodel.cpp#L677 or - mounting a tmpfs with the "noswap,mode=0700,uid=${USER}" options over the default KLIPPER_DATABASE ~/.local/share/klipper/ Even then, data can still be trivially exfilled from files in ${KLIPPER_DATABASE}/data/ and from ${KLIPPER_DATABASE}/history3.sqlite-wal. Owner/permissions on "data/" can be set to prevent listing (so you'd need to know the UUIDs of entries). But even if history3.sqlite-wal is unlinked while open, it can still be read from /proc/$(pidof plasmashell)/fd/<fd # of history3.sqlite-wal>. Which is a long winded way to ask the devs, please, at least allow us to use an in-memory SQLite db. :) -- You are receiving this mail because: You are watching all bug changes.
