Boomaga virtual printer error

I’m using Boomaga to manually print front to back with my Laserjet printer.
Boomaga is now failing with the following error in the logs:

[Boomaga backend] ERROR: Can’t change mode on directory /var/cache/boomaga: Permission denied

Any idea how to fix this issue?

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’.

sudo chown boomaga /var/cache/boomaga
sudo chmod 755 /var/cache/boomaga

Now the directory is owned by the same userid Boomaga uses to run, and that userid has permission to write in that directory.

1 Like

So I ran the following commands with their respective output.

ls -la /var/cache/boomaga

drwxr-xr-x. 1 root root 0 Jan 19 23:39 .
drwxr-xr-x. 1 root root 224 May 11 13:01 .

cat /etc/passwd | grep boomaga gave no results

I tried sudo chmod 755 /var/cache/boomaga but the pernissions didn’t change.

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.

Changing permissions to 777 didn’t solve the problem. Same error pops up in logs.

Looking closely at /etc/passwd the only one that looks related is lp.

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?

1 Like

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.

Tried to temporarily disable selinux with sudo setenforce 0 and this solves the problem.

Dos this mean that this a Boomaga bug or should I post a bug report somewhere else?

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.

1 Like

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.

1 Like

I think there are two issues here:

  • 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.

1 Like

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.

1 Like

So I installed the setroubleshoot-server package to run sealert, but I’m at a loss on how to proceed.

1 Like

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.

When I run sealert in a terminal I get:

could not attach to desktop process

I don’t see any app in the list for sealert. However I installed SELinux Troubleshooter from Gnoem software and got the following error:

SELinux is preventing boomaga from sys_ptrace access on the cap_userns labeled cupsd_t.

1 Like

Odd—you do have some window manager etc. running, right? Maybe it needs a reboot or something, I’m not entirely sure.

Yeh, what sealert will do is also make suggestions on how to fix this and file a bug if necessary. Here’s a screenshot:

You’re right, the full report said:

*****  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?

1 Like

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.

In the process of submitting a bug, I fould that:

  1. There is a boomaga-selinux package that doesn’t solve the problem
  2. There is a bug report already: 1409115 – Incorrect permissons in the RPM package and boomaga requires the SELinux security policy but it is reported as closed.

The error now shows:

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

Not sure how to proceed.

1 Like