KeePassXC & FireJail suddenly began conflicting in my Tower.

English Applications
1

I use FireJail “FJ”] to sandbox many of my regular programs. It worked well for me in Mint KDE & Maui prior to changing to openSUSE Tumbleweed, & it also has been working well for me in oS TW., until a few weeks ago. Since then, all but one program continue to work correctly with FJ, in both my PCs. However suddenly, for no reason i’ve yet determined, a few weeks ago one specific pgm stopped working with FJ… but only in my Tower [it continues to be fine in my Lappy]. That pgm is KeePassXC “KP”].

KP continues to work fine in Tower if i run it naked, ie, not in FJ. For the past few weeks though, it no longer launches with my usual custom FJ launcher. Konsole reveals what happens:


gooeygirl@linux-Tower:~> **firejail --protocol=unix -- keepassxc**
Reading profile /etc/firejail/keepassxc.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Warning: a protocol list is present, the new list "unix" will not be installed
Parent pid 16689, child pid 16690
Child process initialized in 45.22 ms
process 6: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace


Parent is shutting down, bye...
gooeygirl@linux-Tower:~>

In comparison, this is what correct operation looks like [this comes from one of my TW VMs, but is how my Tower itself also used to behave (btw, the green text is NOT a real error; it denotes no internet access, which is the whole point of using the “[i]protocol=unix” option)]:


gooeygirl@linux-bgps:~> **firejail --protocol=unix -- keepassxc**
Reading profile /etc/firejail/keepassxc.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Warning: a protocol list is present, the new list "unix" will not be installed
Parent pid 19039, child pid 19040
Child process initialized in 17.43 ms
Qt: Session management error: Could not open network socket


Parent is shutting down, bye...
gooeygirl@linux-bgps:~>

Omitting the unix option does not help. Removing & reinstalling FJ & KP does not help.

I tried to investigate the red = my colouring, above, for simple clarity in this post] error message’s information, but did not get anywhere:

  1. " “/etc/machine-id”: No such file or directory
    " → is incorrect; this file does exist, & still has correct root ownership & permissions -rw-rw-rw-]. 1. I looked at "man dbus-uuidgen
    ". I took note of:

The primary usage of dbus-uuidgen is to run in the post-install script of a D-Bus package like this:


***             dbus-uuidgen --ensure***


       This will ensure that ***/var/lib/dbus/machine-id*** exists and has the uuid in it. It won't overwrite an existing uuid, since this id should remain fixed for a single machine until the next reboot at least.

OPTIONS
**--ensure=FILENAME]**
           If a filename is not given, defaults to localstatedir/lib/dbus/machine-id (localstatedir is usually /var). If this file exists then it will be
           validated, and a failure code returned if it contains the wrong thing. If the file does not exist, it will be created with a new uuid in it. On
           success, prints no output.

I visually confirmed that /var/lib/dbus/machine-id does also exist & with correct root ownership], indeed it is merely a symlink back to /etc/machine-id. Disbelieving it would help, i executed dbus-uuidgen --ensure … it returned nothing, which according to the man-page is supposedly good news.

I have nothing else to try, no idea why this fault arose, its root cause, nor how to fix it.

Does anyone have any suggestions please?

2

Hi
Since the version is a few releases old in the Virtualization repo (0.9.44.4), suggest you contact the maintainer (email in link) and ask if when they have a spare moment to upgrade to the latest release 0.9.48…
https://build.opensuse.org/package/view_file/Virtualization/firejail/firejail.changes?expand=1

3

Oh, no – i don’t use it from oS repos, i only get it from the FJ website. Hence, my one is already & has been for quite a while]:


gooeygirl@linux-Tower:~> zypper info firejail
Loading repository data...
Reading installed packages...




Information for package firejail:
---------------------------------
Repository     : My_openSUSE_Repo               
Name           : firejail                       
Version        : **0.9.48-1**                       
Arch           : x86_64                         
Vendor         :                                
Installed Size : 850.7 KiB                      
Installed      : Yes                            
Status         : up-to-date                     
Source package : firejail-0.9.48-1.src          
Summary        : Linux namepaces sandbox program
Description    :                                
    Firejail  is  a  SUID sandbox program that reduces the risk of security
    breaches by restricting the running environment of untrusted applications
    using Linux namespaces. It includes a sandbox profile for Mozilla Firefox.                                                                                   
                                                                                                                                                                 
gooeygirl@linux-Tower:~>
4

Maybe try the one in the repo even if a few versions old.

5

Hi
Ahhh, well it maybe something to raise there… do they support Tumbleweed?

As suggested try the one from the openSUSE repo and ask for an update.

6

Thank you both. I have now emailed Takashi-san about possibly bringing the latest versions [FJ & FireTools] into the oS repos. I also asked for any thoughts about the possible root cause & solutions, with reference to this thread.

Regarding the suggestions / recommendations you both made about me trying the old FJ version per the repos, if all other options become eliminated then i might do that, but for now i haven’t*****. Given your remarks, i wish to offer this clarification: logically [at least, as it seems to me], it can’t simply be a problem that my FJ version 0.9.48-1 is incompatible with Tumbleweed per se, &/or is incompatible with KeePassXC, given that for several weeks they were working very nicely together on Tower, & are still working nicely together on Lappy [same TW snapshot].

*****There have been very many bugfixes & major functionality improvements in Fj from 0.9.44 to 0.9.48, such that it’s my judgement that even if FJ .44 were to be ok with Tower’s KP [which based on my info above is a nebulous proposition], i would be incurring a system-wide deterioration of FJ’s efficacy overall & with all my other pgms i use with FJ specifically, all for the sake of a single pgm. Conversely, if i continue using the curent FJ .48, i retain all the system-wide benefits at the [admittedly disappointing] disadvantage of having to run KP “naked”. I wanted to explain my logic to you given i would not want you to feel i was obstinately rejecting your advice just to be aggravating [which i unwittingly might well be, but that’s not my intention at all].

If / depending on any feedback from Takashi-san, i might post this problem on the FJ Dev’s website for direct advice [but at the moment it’s entirely unclear to me if this is a FJ problem, a KP problem, or a TW problem].

Additionally, as soon as i get a chance, i am going to test [in a TW [b]VM, not initially in Tower’s “real” TW] what happens if i were to delete both /etc/machine-id and /var/lib/dbus/machine-id, then execute dbus-uuidgen --ensure. I will create that VM’s TW to mimic my real one, ie, same file-systems, & same encrypted /home & swap… i am interested to see if those IDs somehow tie-in to the encryption, because if they do, & i subsequently delete & create them anew, i wonder if that might render /home unable to be decrypted on login… so i certainly don’t want to try that cold on Tower’s real TW without first knowing.

7

Unfortunately, no joy with the overnight reply from Takashi-san:

> 1. Would it be possible please for you to incorporate the /latest/ versions of FireJail & FireTools in the openSUSE Tumbleweed repositories? They are /firejail-0.9.48-1.x86_64.rpm/ and firetools-0.9.46-1.x86_64.rpm respectively.

**Well, I almost stopped using firejail & co, so I lost my interest. **Can anyone take over the maintenance?

> 2. Do you have any ideas about what might have gone wrong with FireJail on one-only of my two computers, with respect to KeePassXC? They both used to work together correctly on my Tower til recently, & they still do work correctly together on my second pc.

There is no change in firejail side, at least, I haven’t updated it for long time. So sorry, no idea about it.

> 3. Do you think it might be a Tumbleweed problem, or a FireJail problem? [ie, if it is a FireJail problem, then probably i should post it on the FireJail website & ask its Dev for ideas]?

We should update the package at first, maybe some profiles have been updated.

8

An unexpected update:

Now I updated the firejail and firetools package to 0.9.48 and 0.9.46, respectively. Hopefully this worked better on your machine…

Takashi

9

For a multiplicity of reasons that had been growing for weeks, last night i did a fresh install of TW into Tower’s / partition, retaining all other partitions as-is. Post-reboot, my Tower’s TW is now 20170821.

Now, KeePassXC & FireJail once more play nicely together, just like they’d done for a few months in Tower until the abrupt fault arose, & just like they have continued to do in Lappy all along… This is pleasing, but…

…if the fault ever returns, i still have no idea of root cause, hence solution & i acknowledge that a TW reinstallation is more cheating than solution].

Oh well, fingers crossed…

10

On Wed 23 Aug 2017 02:16:02 AM CDT, GooeyGirl wrote:

For a multiplicity of reasons that had been growing for weeks, last
night i did a fresh install of TW into Tower’s / partition, retaining
all other partitions as-is. Post-reboot, my Tower’s TW is now 20170821.

Now, KeePassXC & FireJail once more play nicely together, just like
they’d done for a few months in Tower until the abrupt fault arose, &
just like they have continued to do in Lappy all along… This is
pleasing, but…

…if the fault ever returns, i still have no idea of root cause, hence
solution & i acknowledge that a TW reinstallation is more cheating than
solution].

Oh well, fingers crossed…

Hi
More than likely some underlying library that is common between both, a
big lua rebuild is going on so I have a few old libs lurking…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.79-18.26-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

11

History repeats.

Today i dup’d my 20171018 to 20171027, which thus took Plasma from 5.11.0 to 5.11.2, & KeePassXC from 2.2.1 to 2.2.2. Sadly / annoyingly that collective process brought the unwelcome return of the problem i initially posted in this thread:

gooeygirl@linux-Tower:~> **firejail --protocol=unix -- keepassxc**
Reading profile /etc/firejail/keepassxc.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: a protocol list is present, the new list "unix" will not be installed
Parent pid 6648, child pid 6649
Child process initialized in 66.94 ms
process 7: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace


Parent is shutting down, bye...
gooeygirl@linux-Tower:~>

In one of my 14 August posts in this thread, i wrote this:

Additionally, as soon as i get a chance, i am going to test [in a TW VM, not initially in Tower’s “real” TW] what happens if i were to delete both /etc/machine-id and /var/lib/dbus/machine-id, then execute dbus-uuidgen --ensure. I will create that VM’s TW to mimic my real one, ie, same file-systems, & same encrypted /home & swap… i am interested to see if those IDs somehow tie-in to the encryption, because if they do, & i subsequently delete & create them anew, i wonder if that might render /home unable to be decrypted on login… so i certainly don’t want to try that cold on Tower’s real TW without first knowing.

Today, post-upgrade & reboot, once i discovered the problem had returned, i made a foolish error of judgement. I did only part of my above-quote. I deleted /etc/machine-id but not also /var/lib/dbus/machine-id, then i ran ***dbus-uuidgen --ensure ***… but i did all that in my real TW, not experimenting first in a VM. Whoops. As soon as i did it, FJ & KPXC once again cooperated properly [yay]… but… as i was still curious about if this action might interfere with the encryption of /home [done during original TW installation] i then rebooted. Oh dear. I could no longer properly boot my Tower; it did indeed fail at the decryption password screen, taking me each time to an emergency maintenance type of screen.

The man dbus-uuidgen certainly did warn me, but silly me proceeded anyway…

If you try to change an existing machine-id on a running system, it will probably result in bad things happening. Don’t try to change this file

Thank goodness for BtrFS + Snapper!!! Doing a rollback to the snapshot created after today’s big dup, gave me a working system again… phew. However, i now have to use the AppImage again for KeePassXC, rather than the repo version, in order for successful Firejail integration. That in turn has now brought another unwanted return, as per a parallel thread of mine… AppImages cause cumulative Loop Devices to mount & not automatically unmount again after closing the AI. Sigh.

To be honest, i don’t understand the point of dbus-uuidgen --ensure. Yes it did fix the initial problem, but it caused a vastly larger problem once i rebooted, which kinda sorta means there’s apparently not much point in me ever using it again. Maybe it’s only supposed to be used for non-encrypted /home ?

12

SOLVED it.

Once again i can successfully use the repo’s KeePassXC with Firejail … no need again for the AppImage [& hence, happily, once again the irritation with Loop Devices being mounted by the AI but never unmounted, is again avoided].

My faulty method per my preceding post was close, very close, but i deleted the wrong file, & that’s [presumably] why it then broke the /home Luks encryption.

I tested & verified this root cause & solution first last night on an old TW BtrFS Luks /home VM [ie, identical filesystem & encryption state as my “real” TW] that i’d not dup’d since August. This VM, before upgrading, had a functional KeePassXC with Firejail. After the [huge; >2GB] dup & reboot were done, the VM manifested the identical failure of KeePassXC when trying to use in Firejail, as per my “real” TW’s error msg i’ve earlier posted in this thread. Then, after i deployed the simple solution as written below, all was good once again [including of course that this time the encryption was not damaged thus reboots were still ok].

“Something” in occasional TW upgrades causes this failure … whilst it’s only happened to my “real” TW twice, that’s 2x too many, but at least now the solution is understood & easily utilised. The fact that i have verified the failure & fix also occurs in my various test VMs furthermore proves this is not merely something tangential like a corrupt filesystem or HW fault of my Tower; it’s something contained in occasional TW snapshots themselves.

The Solution:


[ol]
[li]Delete [b][i]/var/lib/dbus/machine-id[/i][/b][/li][li][u]Do NOT delete[/u] [b][i]/etc/machine-id[/i][/b][/li][li]Execute [b][i]sudo dbus-uuidgen --ensure[/i][/b] in Konsole[/li][li]Observe that now a new [u]copy[/u] of[b][i] machine-id[/i][/b] has appeared in [b][i]/var/lib/dbus[/i][/b] [earlier it was only a [u]symlink[/u]][/li][li]KeePassXC now works in Firejail again.[/li][/ol]