[GH-ISSUE #3892] Option to launch firejailed program as a different user

gitea-mirror commented

2026-05-05 09:07:45 -06:00

Owner

Originally created by @scruloose on GitHub (Jan 13, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3892

I would like to revive the request in issue #208 for the ability to run programs inside Firejail as an entirely different local *NIX user.

Similar to the OP of that issue, what I have in mind is something like this:

I have my primary user account on my desktop system, logged in with a full DE;
I also have a secondary user account on the same machine, with its own home folder which in turn contains ~~an extensive porn stash~~ its own persistent .firefox tree for persistent browser settings, the whole meal deal;
The primary user has sudo access;
Using something like sudo firejail --runas=<seconduser> <program-to-run>, I could launch Firefox or SMplayer or whatever, in a Firejail sandbox, using Xpra or Xephyr or whatever, as the secondary user, using that user's own home dir, its own ~/.config tree, its own file-access permissions, its own everything, but export the window back to my existing desktop.

This would allow mixing and matching the strengths of sandboxing with the strengths of *NIX account separation (second user can have a different umask, its own system-enforced disk quota, its own group memberships, etc), while keeping the convenience of a single desktop environment.

Oddly, the thread for issue #208 seems to indicate that this ability was actually added in early 2016… but by a year and a half later it had been "removed a long time ago".

I don't know what prompted the removal of this feature shortly after implementing it, but if it was removed due to factors that are reasonably easy to resolve (or no longer relevant 5 years later), this is something that I for one would find really handy to have.

Originally created by @scruloose on GitHub (Jan 13, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3892 I would like to revive the request in issue #208 for the ability to run programs inside Firejail as an entirely different local *NIX user. Similar to the OP of that issue, what I have in mind is something like this: * I have my primary user account on my desktop system, logged in with a full DE; * I also have a secondary user account on the same machine, with its own home folder which in turn contains <strike>an extensive porn stash</strike> its own persistent `.firefox` tree for persistent browser settings, the whole meal deal; * The primary user has sudo access; * Using something like `sudo firejail --runas=<seconduser> <program-to-run>`, I could launch Firefox or SMplayer or whatever, in a Firejail sandbox, using Xpra or Xephyr or whatever, as the secondary user, using that user's own home dir, its own ~/.config tree, its own file-access permissions, its own everything, **but** export the window back to my existing desktop. This would allow mixing and matching the strengths of sandboxing with the strengths of *NIX account separation (second user can have a different umask, its own system-enforced disk quota, its own group memberships, etc), while keeping the convenience of a single desktop environment. Oddly, the thread for issue #208 seems to indicate that this ability was actually added in early 2016… but by a year and a half later it had been "removed a long time ago". I don't know what prompted the removal of this feature shortly after implementing it, but if it was removed due to factors that are reasonably easy to resolve (or no longer relevant 5 years later), this is something that I for one would find *really* handy to have.

gitea-mirror added the

enhancement

label 2026-05-05 09:07:45 -06:00

gitea-mirror commented

2026-05-05 09:07:47 -06:00

Author

Owner

@ghost commented on GitHub (Jan 14, 2021):

* Using something like `sudo firejail --runas=<seconduser> <program-to-run>`

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

@ghost commented on GitHub (Jan 14, 2021): > * Using something like `sudo firejail --runas=<seconduser> <program-to-run>` Wouldn't this be simply `sudo -u <seconduser> firejail <program-to-run>`?

gitea-mirror commented

2026-05-05 09:07:48 -06:00

Author

Owner

@akhouderchah commented on GitHub (Mar 19, 2021):

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

IIUC, that's assuming seconduser has permission to execute firejail. Given the nature of SUID binaries in the context of privilege escalation, they are high-value targets, and so ideally seconduser wouldn't be able to use firejail. Under the assumption that all processes running as seconduser are sandboxed and have no access to firejail, I'm not sure how much benefit a --user flag would be outside of configuration errors, but retaining that additional layer of security doesn't seem so outlandish for a project specifically designed around security and whose users likely have a {,un}healthy amount of paranoia.

FWIW, it seems like the option was removed specifically under the assumption that a --user flag has no benefit over sudo -u:
ab36d4527f

@akhouderchah commented on GitHub (Mar 19, 2021): > Wouldn't this be simply `sudo -u <seconduser> firejail <program-to-run>`? IIUC, that's assuming seconduser has permission to execute firejail. Given the nature of SUID binaries in the context of privilege escalation, they are high-value targets, and so ideally seconduser wouldn't be able to use firejail. Under the assumption that all processes running as seconduser are sandboxed and have no access to firejail, I'm not sure how much benefit a --user flag would be outside of configuration errors, but retaining that additional layer of security doesn't seem so outlandish for a project specifically designed around security and whose users likely have a {,un}healthy amount of paranoia. FWIW, it seems like the option was removed specifically under the assumption that a --user flag has no benefit over `sudo -u`: https://github.com/netblue30/firejail/commit/ab36d4527faf8eed995c62966fe35ca1062e212b

gitea-mirror commented

2026-05-05 09:07:49 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 6, 2021):

Do we want this or should we close?

@rusty-snake commented on GitHub (Apr 6, 2021): Do we want this or should we close?

gitea-mirror commented

2026-05-05 09:07:50 -06:00

Author

Owner

@kmk3 commented on GitHub (Apr 7, 2021):

@Khouderchah-Alex commented 19 days ago:

Wouldn't this be simply sudo -u <seconduser> firejail <program-to-run>?

IIUC, that's assuming seconduser has permission to execute firejail. Given
the nature of SUID binaries in the context of privilege escalation, they are
high-value targets, and so ideally seconduser wouldn't be able to use
firejail. Under the assumption that all processes running as seconduser are
sandboxed and have no access to firejail, I'm not sure how much benefit a
--user flag would be outside of configuration errors, but retaining that
additional layer of security doesn't seem so outlandish for a project
specifically designed around security and whose users likely have a
{,un}healthy amount of paranoia.

Personally, I have also wondered about this exact same problem.

To me, from a high-level perspective, this:

SUID -> privdrop -> untrusted_user -> program

seems more secure than this:

untrusted_user -> SUID -> privdrop -> program

FWIW, it seems like the option was removed specifically under the assumption
that a --user flag has no benefit over sudo -u:
ab36d45

@rusty-snake commented yesterday:

Do we want this or should we close?

I have no idea about the costs of implementing this, so I'll just leave my "+1
nice to have" here.

@kmk3 commented on GitHub (Apr 7, 2021): @Khouderchah-Alex commented 19 days ago: > > Wouldn't this be simply `sudo -u <seconduser> firejail <program-to-run>`? > > IIUC, that's assuming seconduser has permission to execute firejail. Given > the nature of SUID binaries in the context of privilege escalation, they are > high-value targets, and so ideally seconduser wouldn't be able to use > firejail. Under the assumption that all processes running as seconduser are > sandboxed and have no access to firejail, I'm not sure how much benefit a > --user flag would be outside of configuration errors, but retaining that > additional layer of security doesn't seem so outlandish for a project > specifically designed around security and whose users likely have a > {,un}healthy amount of paranoia. Personally, I have also wondered about this exact same problem. To me, from a high-level perspective, this: * SUID -> privdrop -> untrusted\_user -> program seems more secure than this: * untrusted\_user -> SUID -> privdrop -> program > FWIW, it seems like the option was removed specifically under the assumption > that a --user flag has no benefit over `sudo -u`: > [ab36d45](https://github.com/netblue30/firejail/commit/ab36d4527faf8eed995c62966fe35ca1062e212b) @rusty-snake commented yesterday: > Do we want this or should we close? I have no idea about the costs of implementing this, so I'll just leave my "+1 nice to have" here.

gitea-mirror commented

2026-05-05 09:07:51 -06:00

Author

Owner

@kmk3 commented on GitHub (Apr 7, 2021):

By the way, I see that there is a "wontfix" label, but it is currently only
used for #107 and #1743, and I suspect that there is more of such issues:

https://github.com/netblue30/firejail/issues?q=label%3Awontfix

If this is resolved as a "wontfix", please consider using that label to make it
obvious at a glance why the issue was closed.

@kmk3 commented on GitHub (Apr 7, 2021): By the way, I see that there is a "wontfix" label, but it is currently only used for #107 and #1743, and I suspect that there is more of such issues: * <https://github.com/netblue30/firejail/issues?q=label%3Awontfix> If this is resolved as a "wontfix", please consider using that label to make it obvious at a glance why the issue was closed.

gitea-mirror commented

2026-05-05 09:07:51 -06:00

Author

Owner

@diyism commented on GitHub (Oct 22, 2022):

I'm trying to use firejail in a seperated user:

$ sudo apt install firejail
$ sudo adduser firejail
$ sudo -u firejail firejail pwd
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file

** Note: you can use --noprofile to disable default.profile **

Parent pid 328746, child pid 328747
Error: cannot write to /proc/328747/gid_map: Invalid argument
Error: proc 1 cannot sync with peer: unexpected EOF

How to fix the "Error: cannot write to /proc/328747/gid_map: Invalid argument" ?

@diyism commented on GitHub (Oct 22, 2022): I'm trying to use firejail in a seperated user: ``` $ sudo apt install firejail $ sudo adduser firejail $ sudo -u firejail firejail pwd Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-programs.inc Warning: networking feature is disabled in Firejail configuration file ** Note: you can use --noprofile to disable default.profile ** Parent pid 328746, child pid 328747 Error: cannot write to /proc/328747/gid_map: Invalid argument Error: proc 1 cannot sync with peer: unexpected EOF ``` How to fix the "Error: cannot write to /proc/328747/gid_map: Invalid argument" ?

gitea-mirror commented

2026-05-05 09:07:52 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 22, 2022):

@diyism this is a complete other issue/question. Pleas open a new issue/discussion for it.

@rusty-snake commented on GitHub (Oct 22, 2022): @diyism this is a complete other issue/question. Pleas open a new issue/discussion for it.

gitea-mirror referenced this issue

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

[PR #2444] [MERGED] Harden gnome-recipes.profile #4316

Rows
Columns

[GH-ISSUE #3892] Option to launch firejailed program as a different user #2444