Bug 390830

Major security flaw. Options here:
- Baloo shouldn't index files in vaults at all
- Baloo should index files in vaults, but store that data in a separate index *inside* the vault, and make sure that the index data is not available when the vault is locked

First thought: 
Under the premise all vaults are in ~/Vaults, put ~/Vaults into excludeFolders config by default.

@Venky: Please do this
   $balooctl config add excludeFolders ~/Vaults
or use 
   systemsettings > workspace > search > filesearch
(names may differ)

(Damn, hit tab again)
continuing @Venky:
To be safe you should also rebuild your database.
$ balooctl disable
$ balooctl enable

>i can find vault files in search with a new dolphin window
Dolphin automatically chooses between to search algorithms.
1) When 'More options'-panel is enabled search is done by baloo. Search should not show any vault content. Please confirm!
2) When it is not, a pure filename search is done. Expect results from a mounted vault. You're safe though because nothing is stored.

>vault browser is closed
Please clarify:
- vault is mounted?

Also, I just installed vault to test this. The password dialog continued to pop up until I realized the line beneath the text field: "Failed to open...not empty..."
Maybe you've overlooked that too. And maybe you have a hidden file in you vault mountpoint e.g. ".directory".

(In reply to Nate Graham from comment #1)
> - Baloo should index files in vaults, but store that data in a separate
> index *inside* the vault, and make sure that the index data is not available
> when the vault is locked
Nice, but not feasable - currently

IMO, baloo needs to ignore all FUSE mounts. That's what we did (tried to do) a long time ago with Nepomuk.

A long time ago Vishesh talked about the possibility to have the database distributed across multiple places (useful for removable storage as well as encrypted data), but I guess it was never implemented.

Baloo indexing is not the only thing: the names of the folders within vaults can be seen at /home/user/.local/share/dolphin/view_properties/local/home/user/..., when the vault is closed.

Hmm, that is very bad too. However that's a separate issue in Dolphin unrelated to this particular issue in Baloo. Can you file a new bug report for that? Thanks!

(In reply to Nate Graham from comment #7)
> Hmm, that is very bad too. However that's a separate issue in Dolphin
> unrelated to this particular issue in Baloo. Can you file a new bug report
> for that? Thanks!

Done
https://bugs.kde.org/show_bug.cgi?id=427985

Yep! Thanks!

+1 for this. I was about to report this one. 
I was stunned when I saw the file names in vault appear in Krunner. This must never happen.

Right now, the same result can be observed from Kickoff search too. This is bad.

A possible workaround available in Archlinux wiki.
https://wiki.archlinux.org/title/Baloo#Plasma_Vault_Files_are_indexed_and_available_even_when_vault_is_closed

Okular and Gwenview also don't know about Vaults and collect potentially sensitive metadata in ~/.local/share/okular/docdata and ~/.local/share/gwenview/recentfolders.

> IMO, baloo needs to ignore all FUSE mounts

My merge request that needs review does this, if I'm not mistaken. It's still possible to manually opt in. That may fix this issue. https://invent.kde.org/frameworks/baloo/-/merge_requests/96/

Thanks, I'll see if I can get some attention on that, and give it a whirl myself.

(In reply to Detlef Eppers from comment #13)
> Okular and Gwenview also don't know about Vaults and collect potentially
> sensitive metadata in ~/.local/share/okular/docdata and
> ~/.local/share/gwenview/recentfolders.

Also, thumbnails may leak out. These do not only show the preview, with up to 512x512 pixels, but also contain the full file name.

This only happens when the home directory is on encrypted storage, but when you use Vaults even though the home directory is encrypted, you probably do for a reason (i.e. additional confidentiality).

That is a fairly recent change for the worse, and it was mentioned in the MR (https://invent.kde.org/frameworks/kio/-/merge_requests/1287#note_687728), but people seem to be fine with this.

Yeah, maybe that was a mistake.

Git commit 373cf1e567e2580145f137176d440da27c319f06 by Felix Ernst, on behalf of Adam Fontenot.
Committed on 29/03/2024 at 10:32.
Pushed by felixernst into branch 'master'.

Skip indexing KDE FS volumes unless user included

In 69411a, we changed the indexer behavior so that removable media
is not indexed by default. This commit tries to extend this
behavior to any temporarily mounted file system.

For instance, fuse.sshfs and overlay mounted file systems are
managed in Solid under the /org/kde/fstab parent. Most likely, users
will not want to index these file systems by default.

This commit also changes the initialization procedure for
StorageDevices. We now attempt to create a cached entry for *all*
Solid devices when initializing. It makes sense to do this because
`createCacheEntry` is already called whenever a device is added or
removed, without any further filtering. Trying to precisely specify
which devices to include at the initialization stage risks leaving
out devices like the /org/kde/fstab devices that are the subject
of this PR.
Related: bug 460509

M  +3    -3    src/file/storagedevices.cpp

https://invent.kde.org/frameworks/baloo/-/commit/373cf1e567e2580145f137176d440da27c319f06

The situation of this bug has now been somewhat improved. We do no longer automatically put the vaults in Baloo's index as per commits.kde.org/baloo/373cf1e567e2580145f137176d440da27c319f06. However, as pointed out in other places in this bug report already, there are other less obvious ways how the content of the vault can still be available even after closing it. At least simply searching for the content using Baloo should no longer bring them up.

However, even Baloo itself might still make contents of the vault available after it is closed. I'll quote Stefan Brüns' comment from https://invent.kde.org/frameworks/baloo/-/merge_requests/96#note_897708:

> baloo_file gets information from various sources, inotify for file events,
> process signals, events on file descriptors via Solid (e.g. mtab), events via
> DBus from UDisks, etc. So it is quite common to e.g. get a "directory
> changed" event for a mounted Vault, and some time later the
> corresponding "Device/Filesystem added" added from Solid.
> 
> This will then add data from the Vault to the index, and short time later
> "discard" the information again, as it becomes excluded. Unfortunately,
> the discard only invalidates the data from the index, but the data is still
> there, in plain text (somewhat unstructured, but nevertheless). The user
> may think everything is fine (no confidential data returned when
> searching), but actually it is not.

KWin (x11) hangs when ALT - TAB pressed after suspend/resume. kwin process goes 100% CPU, GUI goes unresponsive, when the process is killed, GUI works again until next alt-tab. Works perfectly fine on first boot.
kwin: 6.1.1
NVidia driver: 555.58

LyCC, please don't change random bugs, your issue is totally unrelated to this one. Search on the tracker if it hasn't been reported already otherwise create a new bug report. Thanks!