github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2388] Retain firejail-local AppArmor customizations #1593

New issue

Closed

opened 2026-05-05 08:14:52 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:14:52 -06:00

Owner

Originally created by @ghost on GitHub (Feb 4, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2388

When installing Firejail a fresh copy of firejail-local gets installed (usually into /etc/apparmor.d/local) by default. While this is fine when users don't add any site-specific additions or overrides to Firejail's default AppArmor profile, this is problematic when they do so. Currently these always seem to get overwritten on each upgrade, causing unnecessary confusion.

This issue usually doesn't show on Arch Linux, as the official repo package isn't enabling apparmor. Unsure about what happens on RPM-based distros, I have zero-experience with those. But on Debian/Ubuntuand friends this should be reproducible.

I only started to use apparmor recently and don't have a lot of experience with it. But it seems to work just fine when enabled on Arch Linux. Am I missing something obvious or is this something we should adress?

Originally created by @ghost on GitHub (Feb 4, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2388 When installing Firejail a fresh copy of [firejail-local](https://github.com/netblue30/firejail/blob/master/etc/firejail-local) gets installed (usually into /etc/apparmor.d/local) by default. While this is fine when users don't add any site-specific additions or overrides to Firejail's [default AppArmor profile](https://github.com/netblue30/firejail/blob/master/etc/firejail-default), this is problematic when they do so. Currently these always seem to get overwritten on each upgrade, causing unnecessary confusion. This issue usually doesn't show on `Arch Linux`, as the [official repo package](https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/firejail) isn't enabling apparmor. Unsure about what happens on RPM-based distros, I have zero-experience with those. But on `Debian/Ubuntu`and friends this should be reproducible. I only started to use apparmor recently and don't have a lot of experience with it. But it seems to work just fine when enabled on Arch Linux. Am I missing something obvious or is this something we should adress?

gitea-mirror closed this issue

2026-05-05 08:14:53 -06:00

gitea-mirror commented

2026-05-05 08:14:55 -06:00

Author

Owner

@ghost commented on GitHub (Feb 4, 2019):

Follow-up: I think this happens due to the following code-block in Makefile.in:

...
ifeq ($(HAVE_APPARMOR),-DHAVE_APPARMOR)
        # install apparmor profile
        sh -c "if [ ! -d $(DESTDIR)/$(sysconfdir)/apparmor.d ]; then install -d -m 755 $(DESTDIR)/$(sysconfdir)/apparmor.d; fi;"
        install -c -m 0644 etc/firejail-default $(DESTDIR)/$(sysconfdir)/apparmor.d/.
        sh -c "if [ ! -d $(DESTDIR)/$(sysconfdir)/apparmor.d/local ]; then install -d -m 755 $(DESTDIR)/$(sysconfdir)/apparmor.d/local; fi;"
        install -c -m 0644 etc/firejail-local $(DESTDIR)/$(sysconfdir)/apparmor.d/local/.
endif
...

With a conditional test to only install firejail-local if it doesn't already exist, this issue/bug could be easily fixed. If only my makefile skills wouldn't be so non-existing I would offer a PR...

But perhaps this can be fixed without needing to touch Makefile.in at all. On Arch Linux one can easily add a file like firejail-local to the backup array in a PKGBUILD. This results in avoiding overwriting files which already exists and were previously modified by the user, which is exactly what seems to be needed/wanted here. Yet I am not aware such a mechanism exists on other distros. Maybe something to ask @reinerh?

@ghost commented on GitHub (Feb 4, 2019): Follow-up: I think this happens due to the following code-block in [Makefile.in](https://github.com/glitsj16/firejail/blob/master/Makefile.in): ``` ... ifeq ($(HAVE_APPARMOR),-DHAVE_APPARMOR) # install apparmor profile sh -c "if [ ! -d $(DESTDIR)/$(sysconfdir)/apparmor.d ]; then install -d -m 755 $(DESTDIR)/$(sysconfdir)/apparmor.d; fi;" install -c -m 0644 etc/firejail-default $(DESTDIR)/$(sysconfdir)/apparmor.d/. sh -c "if [ ! -d $(DESTDIR)/$(sysconfdir)/apparmor.d/local ]; then install -d -m 755 $(DESTDIR)/$(sysconfdir)/apparmor.d/local; fi;" install -c -m 0644 etc/firejail-local $(DESTDIR)/$(sysconfdir)/apparmor.d/local/. endif ... ``` With a `conditional test` to only install firejail-local if it doesn't already exist, this issue/bug could be easily fixed. If only my makefile skills wouldn't be so non-existing I would offer a PR... But perhaps this can be fixed without needing to touch Makefile.in at all. On Arch Linux one can easily add a file like firejail-local to the [backup array in a PKGBUILD](https://wiki.archlinux.org/index.php/PKGBUILD#backup). This results in avoiding overwriting files which already exists and were previously modified by the user, which is exactly what seems to be needed/wanted here. Yet I am not aware such a mechanism exists on other distros. Maybe something to ask @reinerh?

gitea-mirror commented

2026-05-05 08:14:56 -06:00

Author

Owner

@reinerh commented on GitHub (Feb 4, 2019):

Good catch! The Debian package indeed also has this problem.
The /etc/apparmor.d/local/ files are not supposed to be installed by the package itself.
A helper script (generated by dh_apparmor) will create them automatically during installation.
I will fix it in the packaging.
But I think firejail's Makefile should also be changed to not install those files.

@reinerh commented on GitHub (Feb 4, 2019): Good catch! The Debian package indeed also has this problem. The /etc/apparmor.d/local/ files are not supposed to be installed by the package itself. A helper script (generated by [dh_apparmor](https://manpages.debian.org/stretch/dh-apparmor/dh_apparmor.1.en.html)) will create them automatically during installation. I will fix it in the packaging. But I think firejail's Makefile should also be changed to not install those files.

gitea-mirror commented

2026-05-05 08:14:57 -06:00

Author

Owner

@reinerh commented on GitHub (Feb 4, 2019):

Just noticed that it's actually not a big issue on Debian, as the file is marked as a "conffile".
When the user has modified such a file and a package update tries to overwrite it, the user is asked what to do (keep/overwrite/review diff).
But the cleaner way is still to not include it in the package and use dh_apparmor instead.

@reinerh commented on GitHub (Feb 4, 2019): Just noticed that it's actually not a big issue on Debian, as the file is marked as a "conffile". When the user has modified such a file and a package update tries to overwrite it, the user is asked what to do (keep/overwrite/review diff). But the cleaner way is still to not include it in the package and use dh_apparmor instead.

gitea-mirror commented

2026-05-05 08:14:58 -06:00

Author

Owner

@ghost commented on GitHub (Feb 5, 2019):

@reinerh Thanks for looking into this and for pointing to dh_apparmor. I added a preliminary fix in https://github.com/netblue30/firejail/pull/2390. Tested on Ubuntu 16.04 LTS, but that's with a custom script using checkinstall. Let's hold until someone with actual Makefile skills/experience approves the PR.

@ghost commented on GitHub (Feb 5, 2019): @reinerh Thanks for looking into this and for pointing to dh_apparmor. I added a preliminary fix in https://github.com/netblue30/firejail/pull/2390. Tested on Ubuntu 16.04 LTS, but that's with a custom script using checkinstall. Let's hold until someone with actual Makefile skills/experience approves the PR.

gitea-mirror referenced this issue

2026-05-05 10:12:27 -06:00

[PR #1593] [MERGED] Create signal-desktop.profile #4029

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1593

No description provided.

Rows
Columns