Not being familiar with Boomaga, I can only provide suggestions, but that’s what you asked for. The most obvious thing would be to override the current permissions on /var/cache/boomaga to what Boomaga backend expects. If you’re comfortable working at the command line, then … ls -la /var/cache/boomaga
(copy/paste results here with </> so that we can see the current situation)
Look to see if there’s a userid associated with your Boomaga installation (/etc/passwd). Guessing it will be ‘boomaga’. Use that userid in the next command after the word ‘chown’.
Take a look at the users listed in /etc/passwd to see if anything looks likely. But for a temporary solution, sudo chmod 777 /var/cache/boomaga. That allows the universe to write to take directory. Should work for printing now but that leaves a security door open. While printing a document to test this, do the ls -la again. Check the ownership of files now appearing in the cache. That may tell you the owner we need. Another method comes to mind but let’s try this.
Ah, I did some quick research, and I get the idea that your userid needs to be the owner of /var/cache/boomaga. Can you try that?
Along a separate potential problem line, do you have Selinux enabled, and if so, is it complaining about boomaga?
Changing the owner of the folder to my user made the error go away, but still the virtual printer doesn’t open Boomaga.
I didn’t enable selinux myself, but it seems it is default on Fedora. sestatus reports:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
On Ubuntu, my previous Linux distro, I don’t think selinux was enabled, but I may be wrong.
By “solves the problem,” does this mean Boomaga works for you, or just that the Selinux messages stop?
Ideally I think you want Selinux to be working hard to protect your system, without lots of annoying messages, and you want Boomaga working so that you can print double sided.
What I mean by “solves the problem” is that Boomaga works as intended, that is, when I choose to print to the Boomaga virtual printer, the Boomaga GUI is launched and I can print as it is programmed to do.
the user should not have to own the directory in /var—that’s not FHS compliant because /var is a system location. For users, it should be something in $HOME following the XDG specification. This is probably a bug that boomaga need to fix.
it should not be required to turn off selinux. This one needs investigating though because we don’t know if the default policy is not being followed, or if the policy does not include rules for the action that is being carried out here. If you install sealert, it should allow you to troubleshoot this, including filing a bug so that the selinux maintainers can see what needs to be done here.
I agree, Ankur. Looks like in the past, Boomaga’s cache was in the user’s home directory, so the change in location would seem to be a recent and questionable change. And there would appear to be an Selinux rules conflict for the Boomaga support team to address.
So, @entodoays, looks like your system is running but you’ll need to file a problem report with the Boomaga team.
Regarding owning the /var/cache/boomaga folder I reversed the chown back to root since this didn’t solve the problem. Simply pausing selinux was enough.
You should be able to run it in the terminal using sealert, and it should show you the previous alerts with options. Here on gnome, it’s also listed as an app in the applications list. So I expect it should also show up on other DEs.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that boomaga should be allowed sys_ptrace access on cap_userns labeled cupsd_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'boomaga' --raw | audit2allow -M my-boomaga
# semodule -X 300 -i my-boomaga.pp
Additional Information:
Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Objects Unknown [ cap_userns ]
Source boomaga
Source Path boomaga
Port <Unknown>
Host fedora
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch
Local Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name fedora
Platform Linux fedora 5.17.6-300.fc36.x86_64 #1 SMP PREEMPT
Mon May 9 15:47:11 UTC 2022 x86_64 x86_64
Alert Count 18
First Seen 2022-05-17 11:27:53 CEST
Last Seen 2022-05-17 11:27:53 CEST
Local ID 79c2d7ad-d0f4-49f4-8021-79795eaf4f6e
Raw Audit Messages
type=AVC msg=audit(1652779673.743:395): avc: denied { sys_ptrace } for pid=16528 comm="boomaga" capability=19 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=cap_userns permissive=0
Hash: boomaga,cupsd_t,cupsd_t,cap_userns,sys_ptrace
Should I file a bug for selinux in the Fedora bug tracker?
Yes please, that way the maintainers can see if a policy needs to be added or if the printer is doing something wrong which should be reported to their developers.
SELinux is preventing boomaga from setattr access on the directory /var/cache/boomaga/chris.
***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow boomaga to have setattr access on the chris directory
Then you need to change the label on /var/cache/boomaga/chris
Do
# semanage fcontext -a -t FILE_TYPE '/var/cache/boomaga/chris'
where FILE_TYPE is one of the following: cupsd_etc_t, cupsd_log_t, cupsd_rw_etc_t, cupsd_tmp_t, psd_var_run_t, fonts_cache_t, print_spool_t.
Then execute:
restorecon -v '/var/cache/boomaga/chris'
***** Plugin catchall (17.1 confidence) suggests **************************
If you believe that boomaga should be allowed setattr access on the chris directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'boomaga' --raw | audit2allow -M my-boomaga
# semodule -X 300 -i my-boomaga.pp
Additional Information:
Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context system_u:object_r:var_t:s0
Target Objects /var/cache/boomaga/chris [ dir ]
Source boomaga
Source Path boomaga
Port <Unknown>
Host fedora
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch
Local Policy RPM selinux-policy-targeted-36.8-2.fc36.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name fedora
Platform Linux fedora 5.17.7-300.fc36.x86_64 #1 SMP PREEMPT
Thu May 12 14:56:44 UTC 2022 x86_64 x86_64
Alert Count 1
First Seen 2022-05-18 09:25:42 CEST
Last Seen 2022-05-18 09:25:42 CEST
Local ID fcf9d05e-bd5b-4ef6-8a1f-a9a1f94705ff
Raw Audit Messages
type=AVC msg=audit(1652858742.233:473): avc: denied { setattr } for pid=16952 comm="boomaga" name="chris" dev="nvme0n1p7" ino=2129750 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
Hash: boomaga,cupsd_t,var_t,dir,setattr