Pretty self explanatory, generally after closing Wine games, I will get constant pop ups on my desktop about AVC denials from SELinux and I’m not entirely sure what is causing it. I’ve disabled receiving alerts in the notifier, but this doesn’t seem to have helped, so I’ve decided it’s probably better to get to the root of the problem.
I’m not sure what logs I should post, so any assistance would be appreciated.
After doing something that would cause the alerts:
sudo ausearch -m avc,user_avc -ts recent
This is going to get all the avc and user_avc messages that have occurred in the last 10 minutes.
You can search through bugzilla to see if the issue has already been documented, Simple Search
ref:
Here are all the ones that happened around the time when I posted, they all happened within a very short span of time. There are a lot of them so let me know if there is a better format to post them in.
Similar thing happens fairly regularly though.
How did you install/use wine? From Fedora repo, WineHQ repo, via Steam/Lutris, etc
Hadn’t even considered it could be an issue with the version of Wine I’m using until just this. I’ve been noticing the issues most with Proton Experimental, installed via Steam, and I only get the alerts once I close the game, not while its running.
Not necessarily an issue with the wine version, just trying to get info.
It seems like wine (or whatever game) is crashing on quit, abrt (Automatic Bug Reporting Tool) is trying to collect a backtrace with gdb, but they’re not allowed to read all these files—mostly wine libs, and FSD-Win64-Shipping.exe. Is that Deep Rock Galactic?
It says dev=sdb1, is your Steam library in a non-standard location, possibly on a different filesystem like NTFS?
Maybe it’ll be obvious if we check the labels:
locate -0 FSD-Win64-Shipping.exe | xargs -0r ls -lZ
Yes, it is Deep Rock Galactic, I keep my games on a secondary drive, but they’re definitely all ext4.
Output from the command provided
-rwxr-xr-x. 1 alazydope alazydope unconfined_u:object_r:unlabeled_t:s0 108528640 Jun 16 15:37 '/mnt/91605644-410d-457d-9926-187fd4c579ec/Home/SteamLib/steamapps/common/Deep Rock Galactic/FSD/Binaries/Win64/FSD-Win64-Shipping.exe'```sudo semanage fcontext -d "/mnt/[^/]+/Home/SteamLib(/.*)?"
sudo semanage fcontext -a "/mnt/[^/]+/Home/SteamLib(/.*)?" \
-s unconfined_u -t data_home_t
sudo semanage fcontext -l | grep -e Home/SteamLib
sudo restorecon -F -R -T 0 /mnt/*/Home/SteamLib
I get the jist, but could you explain what these are doing?
If I’m using Bottles and Lutris, should I also add the wine homes for those two as well?
It’s writing a new SELinux policy for all files in /mnt/.../SteamLib to use the wine_home_t context (label). (see man semanage-fcontext)
wine_home_t is normally used for ~/.wine. I’m not sure if this is the right choice or we can use something like data_home_t (that’s what a typical Steam install in ~/.local/share/Steam would use). But it should be ok either way.
Then restorecon is re-labelling the files with the updated policy.
Note this (hopefully) fixes the symptom of abrt/gdb not being able to read the files in your Steam library after the game crashes. It doesn’t address the crashing. That might be a game issue not related to wine/Proton.
To be more precise, we do not create a new policy, but add a file context definition to apply the specified filesystem labels used by existing policies.
Agreed, data_home_t looks better, fixed.
Alright, I’ve made these changes, and I suppose we’ll see if this is any better.
Perhaps it will let me find out why it is crashing in the first place.