permission denied error

[jagiella]

I install umu-launcher deb packages on ubuntu 24.04.

Running the launcher always ends up with an permission error:

$ WINEPREFIX=~/path/to/wineprefix/ GAMEID=umu-dauntless PROTONPATH=~/.local/share/Steam/compatibilitytools.d/UMU-Proton-9.0-3 umu-run ~/path/to/game.exe
steamrt is up to date
pressure-vessel-wrap[68721]: E: Der Kindprozess wurde mit Status 1 beendet: bwrap: setting up uid map: Permission denied

[jagiella]

A workaround that solves that problem is tinkering with apparmor: DevToys-app/DevToys#1198 (comment)

But this should not be a prerequist for the launcher to work, right?

[GloriousEggroll]

this will always be a requirement on ubuntu due to Ubuntu developers deciding to use Apparmor to restrict the creation of user namespaces: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces

it may be possible to package an apparmor profile as part of the deb, something we need to look into

[GloriousEggroll]

apparmor profile added #218

[gegarcia]

As @darix has commented on #218, please don't create an "unconfined" profile for bwrap. This completely bypasses the unprivileged user namespace creation restriction and makes the machine exploitable by attacks that use it.

A profile for scripts/programs that call bwrap should be created instead. Please contact the AppArmor community if you need any assistance.

AppArmor upstream has created a profile for bwrap that does not make your machine vulnerable. You can find the profile here. It is not enabled by default on Ubuntu, but you can enable it by either copying the file from gitlab, installing it on /etc/apparmor.d/, and load it using sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict.

You can also use the version shipped by the apparmor-profile package, and create a symbolic link from the extra-profiles directory to /etc/apparmor.d/
sudo ln -s /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/
and load it
sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict.

[darix]

well jjohansen commented that the userns-restrict breaks flatpak. which isnt ideal either. the approach from cboltz would confine what bwrap does to the subprofile of an umu-launcher profile.

I would be happy to help with that. I already did a complete profile set for @GloriousEggroll 's wine build in the past :)

[GloriousEggroll]

from my understanding of all of this, based on gegarcia's comment we just need to remove our current bwrap profile and use bwrap-userns-restrict instead, just rename it so it's umu-specific and so we can add/remove it with the package without interfering with other pre-existing profiles, is that correct? (ex package and ship bwrap-usrns-restrict-umu)

also we need to somehow modify it so it's specific to umu and does not interfere with flatpak -- is that right?

[darix]

naw.

you would do something like

profile umu-launcher /path/to/script/that/calls/bwrap {
   /usr/bin/bwrap cx -> bwrap,
   profile bwrap {
   }
}

that way you have a scoped profile for bwrap.

[gegarcia]

@darix the bwrap profile was missing the "mediate_deleted" flag but that's fixed upstream. we didn't get any other reports of it breaking flatpak (although testing has been limited since the majority is not enabling the profile anymore).

[darix]

aha. well great to know we dont have to go through profiling the umu-launcher scripts :)

[darix]

@GloriousEggroll is bwrap called indirectly via pressure-vessel or so?

[GloriousEggroll]

@GloriousEggroll is bwrap called indirectly via pressure-vessel or so?

yes

[GloriousEggroll]

@darix the bwrap profile was missing the "mediate_deleted" flag but that's fixed upstream. we didn't get any other reports of it breaking flatpak (although testing has been limited since the majority is not enabling the profile anymore).

great so then this should be sufficient hopefully?:

f21c7e6

[darix]

good lord that would have been a profile chain ... or well we could have just profiled pressure-vessel and dont have to start at the umu scripts.

[darix]

great so then this should be sufficient hopefully?:

f21c7e6

for the opensuse rpm i just did ln -s https://build.opensuse.org/projects/games/packages/umu-launcher/files/umu-launcher.spec?expand=1

[GloriousEggroll]

although I suppose I could even just use the same filename and make it a symlink

[GloriousEggroll]

great so then this should be sufficient hopefully?:
f21c7e6

for the opensuse rpm i just did ln -s https://build.opensuse.org/projects/games/packages/umu-launcher/files/umu-launcher.spec?expand=1

yeah i just want to make the name different from the default so that it can be easily added/removed without interfering with other existing files (or in the event that something else already created the symlink or copied the file)

[darix]

yeah that's why i kept the non upstream name for the symlink. i just had to through a lot of profiles and rename them after upstream introduced same profiles with just an empty block to handle userns :)

[GloriousEggroll]

alright here we go, this looks better i think:

0b4b9dc

[darix]

@GloriousEggroll is umu using a system copy of pressure-vessel or the one from steam? i dont see a requires in the rpm spec

[darix]

alright here we go, this looks better i think:

0b4b9dc

why do that in post(rm) scripts instead of in the install section like we would do in rpms?

[GloriousEggroll]

@GloriousEggroll is umu using a system copy of pressure-vessel or the one from steam? i dont see a requires in the rpm spec

it automatically downloads the steam version

[GloriousEggroll]

alright here we go, this looks better i think:
0b4b9dc

why do that in post(rm) scripts instead of in the install section like we would do in rpms?

no reason really, just saw it as an easy way to do it rather than packaging a static symlink

[GloriousEggroll]

there now its a shipped symlink and should link back to the package when checking the file package ownership

418c5d2