Keepassxc: Secret service crash when searching with null baseGroup

[droidmonkey]

I experience the same on fresh install on Arch Linux. From gdb, I got:

ASSERT: "baseGroup" in file /home/invidian/repos/keepassxc/src/core/EntrySearcher.cpp, line 41

#0  0x00007ffff62a2355 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff628b853 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff6a429ac in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#3  0x00007ffff6a41d59 in qt_assert(char const*, char const*, int) () from /usr/lib/libQt5Core.so.5
#4  0x0000555555792888 in EntrySearcher::search (this=0x7fffffffd5a0, searchTerms=..., baseGroup=0x0, forceSearch=false) at /home/invidian/repos/keepassxc/src/core/EntrySearcher.cpp:41
#5  0x00005555557fd8a9 in FdoSecrets::Collection::searchItems (this=0x555558571320, attributes=...) at /home/invidian/repos/keepassxc/src/fdosecrets/objects/Collection.cpp:254
#6  0x00005555557f20ca in FdoSecrets::Service::searchItems (this=0x55555667f3f0, attributes=..., locked=...) at /home/invidian/repos/keepassxc/src/fdosecrets/objects/Service.cpp:267
#7  0x000055555580ae7c in FdoSecrets::ServiceAdaptor::SearchItems (this=0x55555667f730, attributes=..., locked=...) at /home/invidian/repos/keepassxc/src/fdosecrets/objects/adaptors/ServiceAdaptor.cpp:71
#8  0x00005555557de07a in FdoSecrets::ServiceAdaptor::qt_static_metacall (_o=0x55555667f730, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fffffffd8c0)
    at /home/invidian/repos/keepassxc/build/src/fdosecrets/fdosecrets_autogen/ZPMS5EPCTP/moc_ServiceAdaptor.cpp:155
#9  0x00005555557de76b in FdoSecrets::ServiceAdaptor::qt_metacall (this=0x55555667f730, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fffffffd8c0)
    at /home/invidian/repos/keepassxc/build/src/fdosecrets/fdosecrets_autogen/ZPMS5EPCTP/moc_ServiceAdaptor.cpp:313
#10 0x00007ffff6f25fd6 in ?? () from /usr/lib/libQt5DBus.so.5
#11 0x00007ffff6f295cb in ?? () from /usr/lib/libQt5DBus.so.5
#12 0x00007ffff6f29eba in ?? () from /usr/lib/libQt5DBus.so.5
#13 0x00007ffff6f2c388 in ?? () from /usr/lib/libQt5DBus.so.5
#14 0x00007ffff6c911d2 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#15 0x00007ffff77ee702 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#16 0x00007ffff6c647ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#17 0x00007ffff6c672a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#18 0x00007ffff6cbdcf4 in ?? () from /usr/lib/libQt5Core.so.5
#19 0x00007ffff544a43c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x00007ffff54981d9 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0x00007ffff5449221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#22 0x00007ffff6cbd331 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#23 0x00007ffff6c6313c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#24 0x00007ffff6c6b5c4 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#25 0x00005555555c5919 in main (argc=1, argv=0x7fffffffe258) at /home/invidian/repos/keepassxc/src/main.cpp:160

When trying to execute the following command:

secret-tool lookup UserName invidian

Version: 71b05dbcf48efbeb2341f28eac697aaa1616aeb2.

_Originally posted by @invidian in https://github.com/keepassxreboot/keepassxc/issues/5199#issuecomment-674551220_

[Aetf]

I took a brief look: m_exposedGroup should never be nullptr as long as the Collection object exists. This is done by connecting to the following signals:

• groupAboutToRemove signal to reset the exposed group in db metadata
• groupModified signal if moved to recycle bin to reset the exposed group in db metadata
• db metadata change signal to repopulate the db
• the group object is deleted in the db object destructor. This should be handled by databaseReplaced and the databaseLocked signal.

Now given the assert failure, something must go wrong with these. Maybe the group was deleted in another situation and not handled by the above. So it's set to nullptr by the QPointer mechanism.

I'm short on time at the moment so can't investigate further.

[Aetf]

While the stacktrace shows the exact place crashed, it's still unclear to me why that would happen... I tried to reproduce the crash using the latest build of the develop branch with debug build but had no success.

@invidian Could you give more details about how the crash happened? Like the exact steps you did to cause the crash, and what are the settings of the secret service plugin in both app settings and database settings.

[invidian]

@Aetf I can still reproduce it with v2.6.2. Steps to reproduce:

• Enable SSI
• Close KeepassXC
• Open KeepassXC
• Open database
• Run secret-tool lookup UserName invidian

When running keepassxc from the console, I can see the following logs:

$ keepassxc
QDBusConnection: Could not emit signal org.freedesktop.Secret.Service.CollectionCreated: Marshalling failed: Invalid object path passed in arguments
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid object path passed in arguments
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid object path passed in arguments
QDBusConnection: Could not emit signal org.freedesktop.Secret.Service.CollectionChanged: Marshalling failed: Invalid object path passed in arguments
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid object path passed in arguments
Segmentation fault

I guess the OS may make a difference here? I run XFCE on Arch Linux updated to latest version.

[Aetf]

Ok, so there were some errors when creating the collection dbus object, probably due to invalid paths used when registering the object according to the log. As of now, the errors are ignored in the release build. That's why the app crashes later because the internal state is messed up due to the error.

So two actionable here:

• properly handle the dbus path registration error
• figure out why the path is invalid in the first place. The encoding process must be missing a corner case.

What's your database file's file name and the database name? The registration path is built using an encoded version of these.

[invidian]

What's your database file's file name and the database name? The registration path is built using an encoded version of these.

It's .NewDatabase.kdbx and .NewDatabase respectively, as it was auto-generated years ago by KeePass2 :smile:

[Aetf]

Ha, a leading dot! Technically everything after the dot becomes part of the extension, not the base name. Thus the derived registration path is empty.

Working on a fix now.

[invidian]

Ha, a leading dot! Technically everything after the dot becomes part of the extension, not the base name. Thus the derived registration path is empty.

Working on a fix now.

It all make sense! Sorry I didn't provide more details in the first place.

If anyone else is affected by this, it seems renaming database file name makes it work, I can look up entries now!

As a side note, when I renamed the file and re-opened the database, UI still shows old database name, even though I also changed it in database settings:

I wonder if that can be changed somehow too.

[Aetf]

UI still shows old database name

That's the root group's name. You can right-click and change it.

Too many names involved :D

[invidian]

That's the root group's name. You can right-click and change it.

:facepalm: Right, I didn't expect that :smile: Changed now and works like charm! Thanks a lot @Aetf! :pray: :tada:

[chris-echoz]

Ha, a leading dot! Technically everything after the dot becomes part of the extension, not the base name. Thus the derived registration path is empty.

Working on a fix now.

My db file was called .kdbx, this has been driving me crazy, thanks for a workaround until the fix is in the repos :joy: