github-starred/firejail

Fork 0

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

[GH-ISSUE #3833] archivers: issues due limiting file system access #2412

New issue

Closed

opened 2026-05-05 09:05:15 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 09:05:15 -06:00

Owner

Originally created by @ghost on GitHub (Dec 17, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3833

While working on our archiver profiles I started to notice a few things I don't fully understand, or that don't seem to make sense IMO. This all started when I broke a test in a recent PR which prompted @reinerh to pose the question 'why is it not allowed to archive binaries?'. This should be possible - archiving binaries is a legitimate use-case IMO. So I started to drop private-bin from our archivers in #3832.

That triggered the more generic question: why do we impose file system limits in archiver profiles to begin with? Isn't doing so going to break (legitimate) user expectations when archiving stuff for a quick backup of their ${HOME}/.config for example? And what about backing-up /etc?

Realizing it may be a bit over-the-top, I want to propose to drop a few options from the archiver tools to avoid such scenario's:

include disable-foo.inc
private-bin
private-etc
private-lib

All input, thoughts, opinions etcetera on this topic is obviously wanted and very welcome.

Originally created by @ghost on GitHub (Dec 17, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3833 While working on our archiver profiles I started to notice a few things I don't fully understand, or that don't seem to make sense IMO. This all started when I broke a test in a [recent PR](https://github.com/netblue30/firejail/commit/95ad89d24e8e75f2f52defbb80d0d4ee0f27d31e) which prompted @reinerh to pose the question 'why is it not allowed to archive binaries?'. This should be possible - archiving binaries is a legitimate use-case IMO. So I started to drop `private-bin` from our archivers in #3832. That triggered the more generic question: `why do we impose file system limits in archiver profiles to begin with?` Isn't doing so going to break (legitimate) user expectations when archiving stuff for a quick backup of their ${HOME}/.config for example? And what about backing-up /etc? Realizing it may be a bit over-the-top, I want to propose to drop a few options from the archiver tools to avoid such scenario's: - include disable-foo.inc - private-bin - private-etc - private-lib All input, thoughts, opinions etcetera on this topic is obviously wanted and very welcome.

gitea-mirror closed this issue

2026-05-05 09:05:16 -06:00

gitea-mirror commented

2026-05-05 09:05:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 17, 2020):

We can do it like we did with meld. Meld has a legitimate use-case on the most parts of the file-system too.

@rusty-snake commented on GitHub (Dec 17, 2020): We can do it like we did with meld. Meld has a legitimate use-case on the most parts of the file-system too.

gitea-mirror commented

2026-05-05 09:05:19 -06:00

Author

Owner

@ghost commented on GitHub (Dec 17, 2020):

I created a preliminary PR implementing the suggested meld approach. Also added a note to explain the difference between loosening/tightening all archivers at once via archiver-common.local OR doing so per archiver in the relevant .local. Let's keep this open for a while so other people can voice their opinions.

@ghost commented on GitHub (Dec 17, 2020): I created a preliminary PR implementing the suggested meld approach. Also added a note to explain the difference between loosening/tightening **all** archivers at once via archiver-common.local OR doing so **per archiver** in the relevant <foo>.local. Let's keep this open for a while so other people can voice their opinions.

gitea-mirror commented

2026-05-05 09:05:20 -06:00

Author

Owner

@kmk3 commented on GitHub (Dec 27, 2020):

glitsj16 commented 11 days ago

That triggered the more generic question: why do we impose file system limits in archiver profiles to begin with? Isn't doing so going to break
(legitimate) user expectations when archiving stuff for a quick backup of
their ${HOME}/.config for example?

Indeed, and considering that this is the default profile and not a hardened
alternative, I personally would only block things that aren't meant to be read
directly, like character devices in /dev. I have archived ${HOME}/.config
and what not many times and having something like that fail without me noticing
(e.g.: due to a whitelist) could mean loss of data.

Ideally, it would be at least as simple as adding ignore whitelist * +
ignore blacklist * to the relevant profiles. I was thinking about a similar
problem this week: if there was a profile for ls enabled by default, any
blacklist/whitelist would result in subtly wrong output being produced (like
x11 none == ~/.Xauthority appears to be owned by root), which could result
in much confusion since the profile would have to be quiet.

And what about backing-up /etc?

Yes; sometimes I use tar czf etc.tar.gz /etc to quickly back it up before
reinstalling a distro.

So, considering the current profile:

These seem workable:

private-cache # mesa_shader_cache might be worthy of backup because some shader compilation == stuttering
private-dev # there could be some useful metadata worth backing up, but idk

But I would drop this:

disable-passwdmgr.inc # because of blacklist ${HOME}/.config/...

And these could be a problem when backing things up, especially if scripting
and/or many machines are involved:

hostname archiver
machine-id

rusty-snake commented 10 days ago

We can do it like we did with meld. Meld has a legitimate use-case on the
most parts of the file-system too.

To add to that, when I started using firejail (in mid 2019 I think), I was
stunned at getting "file not found" when trying to diff files in /tmp with
Meld. It was because of private-tmp, but it took me a while to figure that
out, as it was one of the first (if not the first) times I had to debug
firejail profiles.

@kmk3 commented on GitHub (Dec 27, 2020): glitsj16 commented 11 days ago > That triggered the more generic question: `why do we impose file system > limits in archiver profiles to begin with?` Isn't doing so going to break > (legitimate) user expectations when archiving stuff for a quick backup of > their ${HOME}/.config for example? Indeed, and considering that this is the default profile and not a hardened alternative, I personally would only block things that aren't meant to be read directly, like character devices in /dev. I have archived `${HOME}/.config` and what not many times and having something like that fail without me noticing (e.g.: due to a `whitelist`) could mean loss of data. Ideally, it would be at least as simple as adding `ignore whitelist *` + `ignore blacklist *` to the relevant profiles. I was thinking about a similar problem this week: if there was a profile for `ls` enabled by default, any blacklist/whitelist would result in subtly wrong output being produced (like `x11 none` == `~/.Xauthority` appears to be owned by root), which could result in much confusion since the profile would have to be `quiet`. > And what about backing-up /etc? Yes; sometimes I use `tar czf etc.tar.gz /etc` to quickly back it up before reinstalling a distro. So, considering the current profile: These seem workable: ```firejail private-cache # mesa_shader_cache might be worthy of backup because some shader compilation == stuttering private-dev # there could be some useful metadata worth backing up, but idk ``` But I would drop this: ```firejail disable-passwdmgr.inc # because of blacklist ${HOME}/.config/... ``` And these could be a problem when backing things up, especially if scripting and/or many machines are involved: ```firejail hostname archiver machine-id ``` rusty-snake commented 10 days ago > We can do it like we did with meld. Meld has a legitimate use-case on the > most parts of the file-system too. To add to that, when I started using firejail (in mid 2019 I think), I was stunned at getting "file not found" when trying to diff files in /tmp with Meld. It was because of `private-tmp`, but it took me a while to figure that out, as it was one of the first (if not the first) times I had to debug firejail profiles.

gitea-mirror commented

2026-05-05 09:05:21 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 8, 2021):

Anything left here or can we close?

@rusty-snake commented on GitHub (Mar 8, 2021): Anything left here or can we close?

gitea-mirror commented

2026-05-05 09:05:22 -06:00

Author

Owner

@ghost commented on GitHub (Mar 8, 2021):

Anything left here or can we close?

Nothing left, closing time!

@ghost commented on GitHub (Mar 8, 2021): > Anything left here or can we close? Nothing left, closing time!

gitea-mirror referenced this issue

2026-05-05 10:17:22 -06:00

[PR #2412] [MERGED] Add profiles for mypaint & mypaint-ora-thumbnailer #4292

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#2412

No description provided.

Rows
Columns