[GH-ISSUE #1988] Profile option to access files in CLI arguments #1339

Closed
opened 2026-05-05 07:53:46 -06:00 by gitea-mirror · 7 comments
Owner

Originally created by @nikolay-turpitko on GitHub (Jun 11, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1988

Please add (or suggest if can be achieved with existing features) an option to enable in the profile config an access to the all files, listed in the command's CLI arguments. For example, i use such programs as Midnight Commander and mutt, which are configured to invoke certain commands to preview files (pdftotext, lynx, ...). Those commands are sandboxed and have no access to files they are invoked with. Say, lynx can be invoked with temporary file in the /tmp, or with file in the /home dir as an argument:

    firejail /usr/bin/lynx -dump -force_html /home/some-sub-dir/index.html .

It's perfectly OK to give it access to any file, provided as it's command line argument. I assume, that I tell it explicit enough that I want it to be able to access this file. It's not desirable to give command access to all other files in the /home directory via profile, if they are not listed on the command line. It's not desirable to whitelist this file via firejail CLI argument, because I'll need to change config of every tool so that every tool be aware about firejail. I mean, I'll need to change configs of mc, mutt, vfm and whatever tool I may use to invoke those sandboxed programs.

What I'd prefer is to put some option in my custom firejail config, to say it what I want to do with files on the command line. Something like: cli-args: no-blacklist,read-only, cli-args: whitelist, cli-args: mkfile (copy), or other way around - add special notation for cli-args to be added to existing options. Like: read-only: <cli-args>.

Originally created by @nikolay-turpitko on GitHub (Jun 11, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1988 Please add (or suggest if can be achieved with existing features) an option to enable in the profile config an access to the all files, listed in the command's CLI arguments. For example, i use such programs as `Midnight Commander` and `mutt`, which are configured to invoke certain commands to preview files (`pdftotext`, `lynx`, ...). Those commands are sandboxed and have no access to files they are invoked with. Say, `lynx` can be invoked with temporary file in the `/tmp`, or with file in the `/home` dir as an argument: firejail /usr/bin/lynx -dump -force_html /home/some-sub-dir/index.html . It's perfectly OK to give it access to any file, provided as it's command line argument. I assume, that I tell it explicit enough that I want it to be able to access this file. It's not desirable to give command access to all other files in the `/home` directory via profile, if they are not listed on the command line. It's not desirable to whitelist this file via `firejail` CLI argument, because I'll need to change config of every tool so that every tool be aware about `firejail`. I mean, I'll need to change configs of `mc`, `mutt`, `vfm` and whatever tool I may use to invoke those sandboxed programs. What I'd prefer is to put some option in my custom firejail config, to say it what I want to do with files on the command line. Something like: `cli-args: no-blacklist,read-only`, `cli-args: whitelist`, `cli-args: mkfile` (copy), or other way around - add special notation for `cli-args` to be added to existing options. Like: `read-only: <cli-args>`.
gitea-mirror 2026-05-05 07:53:46 -06:00
Author
Owner

@chiraag-nataraj commented on GitHub (Jun 11, 2018):

So...I know this doesn't already exist (I'll mark it as an enhancement), but here's what I currently do to get around this.

  1. In the case of emacs, I sandbox the daemon to the point where it can't really do much (no internet access, no sudo access, only allowing Documents, Downloads, and a handful of private information in my home directory, etc). Since I call emacsclient through mutt with an argument in /tmp/user/1000/, this doesn't break and emacsclient is so well protected it's basically a non-issue.
  2. In the case of a script I wrote to download podcasts using rawdog, I dynamically whitelist files based on what the argument was. So basically, I have a systemd service file which is run by a timer, and that service file directly runs firejail with whichever specific whitelisted files I need (in that specific case, I don't even have a profile file, but this would work nicely in conjunction with a profile file where you would whitelist the directories and files necessary for the program to function in the profile and you'd whitelist additional files and directories through the command-line argument).
  3. In the case of mutt and most programs with internet access, I designate some directories as 'common' directories. In my case, I use ~/Downloads for this purpose. Any file I want mutt or firefox or whatever to have access to, I put in ~/Downloads (if it's already in my home directory, a hard link is enough). This has the benefit that I know at a glance what every program can access and what is segregated between programs. So, for example, if I want to view a local html file in lynx or firefox or whatever, I force myself to copy it or hard link it or whatever into ~/Downloads.
<!-- gh-comment-id:396187938 --> @chiraag-nataraj commented on GitHub (Jun 11, 2018): So...I know this doesn't already exist (I'll mark it as an enhancement), but here's what I currently do to get around this. 1. In the case of emacs, I sandbox the daemon to the point where it can't really do much (no internet access, no sudo access, only allowing Documents, Downloads, and a handful of private information in my home directory, etc). Since I call emacsclient through mutt with an argument in `/tmp/user/1000/`, this doesn't break and emacsclient is so well protected it's basically a non-issue. 2. In the case of a script I wrote to download podcasts using rawdog, I dynamically whitelist files based on what the argument was. So basically, I have a systemd service file which is run by a timer, and that service file directly runs firejail with whichever specific whitelisted files I need (in that specific case, I don't even have a profile file, but this would work nicely in conjunction with a profile file where you would whitelist the directories and files necessary for the program to function in the profile and you'd whitelist additional files and directories through the command-line argument). 3. In the case of mutt and most programs with internet access, I designate some directories as 'common' directories. In my case, I use ~/Downloads for this purpose. Any file I want mutt or firefox or whatever to have access to, I put in ~/Downloads (if it's already in my home directory, a hard link is enough). This has the benefit that I know at a glance what every program can access and what is segregated between programs. So, for example, if I want to view a local html file in lynx or firefox or whatever, I force myself to copy it or hard link it or whatever into ~/Downloads.
Author
Owner

@nikolay-turpitko commented on GitHub (Jun 11, 2018):

@chiraag-nataraj

Thanks for your detailed replay, but I'm not sure if I can apply it to my cases.

OK, let's leave mutt aside, it works mostly with /tmp dir and I can just allow access to it for some tools like lynx and pdftotext.

My other use case, which I don't know how to solve properly, is mc (midnight commander, it's a console file manager). I am not sandboxing mc, of course, I need it have access to whatever file in the system. mc has plugable viewers, it can invoke any tool, registered for file type, when I press F3 to preview the file. For example, for pdf files it invokes pdftotext, which has default firejail profile, installed with Debian package. Which is cool. And normally I don't wan't pdftotext has access to any other file, except one I passed to it via command line. The thing is, I may want to preview any file in any directory using mc. For example, I may have Projects dir, which I especially want to protect from incident corruption, and I'm glad firejail can blacklist it for many programs. I don't want to open this dir to any tool by default. At the same time, I heavily use mc for development and like to preview some files in the Projects dir. In case when I hit F3 on the file I want the tool have access to the file. Mostly I want a viewer has read-only access. Probably, there could be cases, when I may want to give write access, though I haven't encountered such cases yet. So, the point is, pdftotext should not have access to the Projects dir. It should have an access only to that one file I give it via argument. It'd be very inconvenient to invoke something like firejail --noblacklist=/my.pdf pdftotext /my.pdf because settings are not in one place. mc has it's own script, where some file types are specified, some files it doesn't know it delegates to xdg-open, other file types may end up in the .mailcap etc. Moreover, I'd like those settings, specific to firejail were encapsulated in firejail profiles, not scattered all over other dotfiles. So that I could reuse them with or without firejail installed, for example.

So, in this case I cannot automatically copy file into known shared dir, like /tmp (or can I?), and don't see how to use cron/systemd to whitelist file, because I cannot predict when I may need which one. Copying file may be doable, I'll check if mc has some option for it. Though I don't much like the idea to even temporary copy my precious private files into some other dir.

<!-- gh-comment-id:396219139 --> @nikolay-turpitko commented on GitHub (Jun 11, 2018): @chiraag-nataraj Thanks for your detailed replay, but I'm not sure if I can apply it to my cases. OK, let's leave `mutt` aside, it works mostly with `/tmp` dir and I can just allow access to it for some tools like `lynx` and `pdftotext`. My other use case, which I don't know how to solve properly, is `mc` (midnight commander, it's a console file manager). I am not sandboxing `mc`, of course, I need it have access to whatever file in the system. `mc` has plugable viewers, it can invoke any tool, registered for file type, when I press `F3` to preview the file. For example, for pdf files it invokes `pdftotext`, which has default firejail profile, installed with Debian package. Which is cool. And normally I don't wan't `pdftotext` has access to any other file, except one I passed to it via command line. The thing is, I may want to preview any file in any directory using `mc`. For example, I may have `Projects` dir, which I especially want to protect from incident corruption, and I'm glad firejail can blacklist it for many programs. I don't want to open this dir to any tool by default. At the same time, I heavily use `mc` for development and like to preview some files in the `Projects` dir. In case when I hit `F3` on the file I want the tool have access to the file. Mostly I want a viewer has read-only access. Probably, there could be cases, when I may want to give write access, though I haven't encountered such cases yet. So, the point is, `pdftotext` should not have access to the `Projects` dir. It should have an access only to that one file I give it via argument. It'd be very inconvenient to invoke something like `firejail --noblacklist=/my.pdf pdftotext /my.pdf` because settings are not in one place. `mc` has it's own script, where some file types are specified, some files it doesn't know it delegates to `xdg-open`, other file types may end up in the `.mailcap` etc. Moreover, I'd like those settings, specific to `firejail` were encapsulated in firejail profiles, not scattered all over other dotfiles. So that I could reuse them with or without `firejail` installed, for example. So, in this case I cannot automatically copy file into known shared dir, like `/tmp` (or can I?), and don't see how to use cron/systemd to whitelist file, because I cannot predict when I may need which one. Copying file may be doable, I'll check if `mc` has some option for it. Though I don't much like the idea to even temporary copy my precious private files into some other dir.
Author
Owner

@chiraag-nataraj commented on GitHub (Jun 11, 2018):

So in this case, I would do option (2) from my list above. Create a handler script which invokes firejail with the appropriate arguments. This way, you can have all programs use that script and can easily toggle whether firejail is invoked without the other programs knowing anything.

For example, I have a script called fx in ~/scripts. The main reason I do this is that I dynamically generate the private-lib list (since the default seems to be broken?) and I want to use systemd-run to ensure it's run as its own (transient) unit. I could set fx to be used for all web browsing stuff (including xdg-open etc), which would mean that if I wanted to toggle using firejail, I just edit the script. This way, it's as centralized as you would like (firejail use is controlled by one script) and you can do whatever whitelisting you want within the script while keeping it completely transparent to other programs. I use my script (fx) as the URL handler in urxvt, for example. urxvt has absolutely no idea that the script is using systemd-run or that I'm invoking firejail. All it knows is that it invokes the script fx with the URL argument, and fx takes care of the rest.

<!-- gh-comment-id:396224258 --> @chiraag-nataraj commented on GitHub (Jun 11, 2018): So in this case, I would do option (2) from my list above. Create a handler script which invokes firejail with the appropriate arguments. This way, you can have all programs use that script and can easily toggle whether firejail is invoked without the other programs knowing anything. For example, I have a script called `fx` in `~/scripts`. The main reason I do this is that I dynamically generate the `private-lib` list (since the default seems to be broken?) and I want to use `systemd-run` to ensure it's run as its own (transient) unit. I could set `fx` to be used for all web browsing stuff (including `xdg-open` etc), which would mean that if I wanted to toggle using firejail, I just edit the script. This way, it's as centralized as you would like (firejail use is controlled by one script) and you can do whatever whitelisting you want within the script while keeping it completely transparent to other programs. I use my script (`fx`) as the URL handler in `urxvt`, for example. `urxvt` has absolutely no idea that the script is using `systemd-run` or that I'm invoking `firejail`. All it knows is that it invokes the script `fx` with the URL argument, and `fx` takes care of the rest.
Author
Owner

@nikolay-turpitko commented on GitHub (Jun 11, 2018):

Hmm... Can I invoke some script from within firejail profile then? I don't want mc be aware even about my own script. It has a bunch of it's own scripts for many file types, supported by the community. I don't want to mangle them. They can be updated with package manager, for example. Also, there can be a lot individual commands to change. Though, I think I understood your idea, thanks. I'll see if I can do something like that. But if firejail profile allows some dynamic, it can be helpful too. And my first idea about profile option for cli arguments - please consider it too.

<!-- gh-comment-id:396227158 --> @nikolay-turpitko commented on GitHub (Jun 11, 2018): Hmm... Can I invoke some script from within firejail profile then? I don't want `mc` be aware even about my own script. It has a bunch of it's own scripts for many file types, supported by the community. I don't want to mangle them. They can be updated with package manager, for example. Also, there can be a lot individual commands to change. Though, I think I understood your idea, thanks. I'll see if I can do something like that. But if firejail profile allows some dynamic, it can be helpful too. And my first idea about profile option for cli arguments - please consider it too.
Author
Owner

@chiraag-nataraj commented on GitHub (Jun 11, 2018):

But whatever the defaults are, you should be able to override it in a per-user configuration, in which case the system defaults don't matter (such defaults exist for urxvt, for example). And yes, you can invoke scripts from within firejail, but then you'd need to configure mc to be aware of firejail, which goes against the whole point!

If I understood correctly, you were asking for a way to be able to set up firejail with other programs not knowing (basically, a firejail-agnostic setup). That is certainly possble right now, either through firecfg (but note that you can't pass additional arguments to firejail that way) or through a custom script. Since you can't pass additional arguments to firejail when you use firecfg, I suggested the script approach.

Looking at the mc man page, I see that you can set up your per-user per-extension defaults in ~/.config/mc/mc.ext (see the man page for more info as to the format, etc). This means you basically need to add a line of the type:

type/<mimetype>
 Open=/path/to/script

(note the leading space on the second line...I think that's how this works, at least after a cursory glance at the man page). You can get the mimetype by using file /path/to/example/file (I presume there's also something in mc that tells you the mimetype). What you're asking for is eminently doable, at least for mc, without touching global configuration (so system-wide defaults can be updated as usual and you don't have to care). Same goes for xdg-open - I believe you should be able to set stuff using xdg-settings, but I don't really use it, so YMMV.

Also, if you don't want your firejail scripts cluttering up the rest of your scripts, you can put them somewhere outside the normal path (e.g. ~/.config/firejail/scripts/), which, as a bonus, means programs running under firejail won't be able to access them (if you want them accessible, you should put them somewhere else...a good place might be ~/.firejail/).

I wonder what @netblue30 thinks of this proposal.

<!-- gh-comment-id:396244787 --> @chiraag-nataraj commented on GitHub (Jun 11, 2018): But whatever the defaults are, you should be able to override it in a per-user configuration, in which case the system defaults don't matter (such defaults exist for `urxvt`, for example). And yes, you can invoke scripts from within firejail, but then you'd need to configure `mc` to be aware of `firejail`, which goes against the whole point! If I understood correctly, you were asking for a way to be able to set up firejail with other programs not knowing (basically, a `firejail`-agnostic setup). That is certainly possble right now, either through `firecfg` (but note that you can't pass additional arguments to `firejail` that way) or through a custom script. Since you can't pass additional arguments to `firejail` when you use `firecfg`, I suggested the script approach. Looking at the `mc` man page, I see that you can set up your per-user per-extension defaults in `~/.config/mc/mc.ext` (see the man page for more info as to the format, etc). This means you basically need to add a line of the type: ``` type/<mimetype> Open=/path/to/script ``` (note the leading space on the second line...I _think_ that's how this works, at least after a cursory glance at the man page). You can get the mimetype by using `file /path/to/example/file` (I presume there's also something in `mc` that tells you the mimetype). What you're asking for is eminently doable, at least for `mc`, without touching global configuration (so system-wide defaults can be updated as usual and you don't have to care). Same goes for `xdg-open` - I believe you should be able to set stuff using `xdg-settings`, but I don't really use it, so YMMV. Also, if you don't want your firejail scripts cluttering up the rest of your scripts, you can put them somewhere outside the normal path (e.g. `~/.config/firejail/scripts/`), which, as a bonus, means programs running under `firejail` won't be able to access them (if you want them accessible, you should put them somewhere else...a good place might be `~/.firejail/`). I wonder what @netblue30 thinks of this proposal.
Author
Owner

@nikolay-turpitko commented on GitHub (Jun 21, 2018):

@chiraag-nataraj
@netblue30
OK, I'm closing this issue. I solved my particular case by other means, but I still think, that feature I suggested in the initial post might be useful, it's up to you to decide if it worth to be implemented and in which form. I think you've got notifications, so there is no need to keep this issue opened.

For those who will face the same problem and might be interested in the solution: I think solution, suggested by chiraag-nataraj (proxy script) might work, but it's a bit more complicated to support, then I'm willing to invest into such thing (though, I may return to it later). Meantime I just whitelisted (in my custom profile) directories I'm using more frequently and will see if it's enough for me.

@chiraag-nataraj Thank you for your efforts and shared ideas. Also, you mentioned that it's possible to invoke scripts from firejail profile to dynamically adjust it (at least it was what I asked about and you answered that it's possible). Could you please point me to the documentation or source code for the feature? I'll see if I can use it in this or other use cases. Thanks.

<!-- gh-comment-id:398983116 --> @nikolay-turpitko commented on GitHub (Jun 21, 2018): @chiraag-nataraj @netblue30 OK, I'm closing this issue. I solved my particular case by other means, but I still think, that feature I suggested in the initial post might be useful, it's up to you to decide if it worth to be implemented and in which form. I think you've got notifications, so there is no need to keep this issue opened. For those who will face the same problem and might be interested in the solution: I think solution, suggested by chiraag-nataraj (proxy script) might work, but it's a bit more complicated to support, then I'm willing to invest into such thing (though, I may return to it later). Meantime I just whitelisted (in my custom profile) directories I'm using more frequently and will see if it's enough for me. @chiraag-nataraj Thank you for your efforts and shared ideas. Also, you mentioned that it's possible to invoke scripts from firejail profile to dynamically adjust it (at least it was what I asked about and you answered that it's possible). Could you please point me to the documentation or source code for the feature? I'll see if I can use it in this or other use cases. Thanks.
Author
Owner

@chiraag-nataraj commented on GitHub (Jun 25, 2018):

@nikolay-turpitko I probably misunderstood you. At this time, afaik, it's not possible to run scripts from within the firejail profile to dynamically adjust it. But, you can run a script within firejail (firejail /path/to/script.sh) or run firejail from within a script, which is what I think I thought you meant 😜 Sorry for the confusion.

<!-- gh-comment-id:399950619 --> @chiraag-nataraj commented on GitHub (Jun 25, 2018): @nikolay-turpitko I probably misunderstood you. At this time, afaik, it's not possible to run scripts from within the firejail profile to dynamically adjust it. But, you can run a script within firejail (`firejail /path/to/script.sh`) or run firejail from within a script, which is what I think I thought you meant :stuck_out_tongue_winking_eye: Sorry for the confusion.
Sign in to join this conversation.
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#1339
No description provided.