[GH-ISSUE #208] option to change user

gitea-mirror commented

2026-05-05 05:09:46 -06:00

Owner

Originally created by @the8472 on GitHub (Jan 3, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/208

Currently it's only possible to bind-mount paths when called by root.

But calling as root prevents passing --noroot which in turn necessitates changing the user within the sandbox via su or sudo and possibly unshare to do what --noroot normally would.

But all those do require more capabilities/system calls than necessary.

So i think it would be useful to drop capabilities, change user and create a user namespace in one go.

Originally created by @the8472 on GitHub (Jan 3, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/208 Currently it's only possible to bind-mount paths when called by root. But calling as root prevents passing `--noroot` which in turn necessitates changing the user within the sandbox via `su` or `sudo` and possibly `unshare` to do what `--noroot` normally would. But all those do require more capabilities/system calls than necessary. So i think it would be useful to drop capabilities, change user and create a user namespace in one go.

gitea-mirror

2026-05-05 05:09:46 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

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

Author

Owner

@genodeftest commented on GitHub (Jan 14, 2016):

Do you want to run e.g. firefox as a different user inside your own home directory?

@genodeftest commented on GitHub (Jan 14, 2016): Do you want to run e.g. firefox as a different user inside your own home directory?

gitea-mirror commented

2026-05-05 05:09:54 -06:00

Author

Owner

@the8472 commented on GitHub (Jan 14, 2016):

the idea is to have a user and home directory dedicated to a specific application, that makes it much simpler to reason about file permissions

@the8472 commented on GitHub (Jan 14, 2016): the idea is to have a user and home directory dedicated to a specific application, that makes it much simpler to reason about file permissions

gitea-mirror commented

2026-05-05 05:09:56 -06:00

Author

Owner

@genodeftest commented on GitHub (Jan 14, 2016):

So for e.g. firefox you won't run it from /home/username but e.g. from /home/username.firefox, right?
And you could put your username.firefox inside the same group as username so you can create files writeable by username and readable by group.

@genodeftest commented on GitHub (Jan 14, 2016): So for e.g. firefox you won't run it from /home/username but e.g. from /home/username.firefox, right? And you could put your username.firefox inside the same group as username so you can create files writeable by username and readable by group.

gitea-mirror commented

2026-05-05 05:09:59 -06:00

Author

Owner

@the8472 commented on GitHub (Jan 14, 2016):

My particular use case is to start daemons which need both network and filesystem access from root, which makes them prime candidates for jailing. Currently the choices for that are either calling su -c "firejail --noroot <daemon>" <user> or firejail ... su -c "<daemon>" <user>. Both have their own drawbacks.

Letting non-root users do that would seem tricky to get right, since it could be easily exploited to gain access to other users if not done right.

@the8472 commented on GitHub (Jan 14, 2016): My particular use case is to start daemons which need both network and filesystem access from root, which makes them prime candidates for jailing. Currently the choices for that are either calling `su -c "firejail --noroot <daemon>" <user>` or `firejail ... su -c "<daemon>" <user>`. Both have their own drawbacks. Letting non-root users do that would seem tricky to get right, since it could be easily exploited to gain access to other users if not done right.

gitea-mirror commented

2026-05-05 05:10:01 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 15, 2016):

I think I'll stay away from it, it creates to many security problems. In order to do it right, I'll end up duplicating all su code into firejail.

@netblue30 commented on GitHub (Jan 15, 2016): I think I'll stay away from it, it creates to many security problems. In order to do it right, I'll end up duplicating all su code into firejail.

gitea-mirror commented

2026-05-05 05:10:03 -06:00

Author

Owner

@the8472 commented on GitHub (Jan 17, 2016):

Would it be possible to delegate this task to su then and insert it between the parent and child firejail instances?

@the8472 commented on GitHub (Jan 17, 2016): Would it be possible to delegate this task to su then and insert it between the parent and child firejail instances?

gitea-mirror commented

2026-05-05 05:10:05 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 18, 2016):

The problem is you need to start the sandbox as root, otherwise I cannot let you change the user. Firejail is SUID binary and can change to any user, but we just cannot let it do it for a regular user.

Support for changing the user makes more sense when running servers. Maybe I'll add some support for it, but the user will need to be root to begin it.

@netblue30 commented on GitHub (Jan 18, 2016): The problem is you need to start the sandbox as root, otherwise I cannot let you change the user. Firejail is SUID binary and can change to any user, but we just cannot let it do it for a regular user. Support for changing the user makes more sense when running servers. Maybe I'll add some support for it, but the user will need to be root to begin it.

gitea-mirror commented

2026-05-05 05:10:07 -06:00

Author

Owner

@the8472 commented on GitHub (Jan 18, 2016):

Yes, starting it as root was my use-case.

@the8472 commented on GitHub (Jan 18, 2016): Yes, starting it as root was my use-case.

gitea-mirror commented

2026-05-05 05:10:09 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 18, 2016):

OK, that's easier. I'll implement it.

@netblue30 commented on GitHub (Jan 18, 2016): OK, that's easier. I'll implement it.

gitea-mirror commented

2026-05-05 05:10:11 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 23, 2016):

I have it ready in the latest version in git. Example:

$ sudo firejail --user=some-other-user firefox

@netblue30 commented on GitHub (Jan 23, 2016): I have it ready in the latest version in git. Example: $ sudo firejail --user=some-other-user firefox

gitea-mirror commented

2026-05-05 05:10:13 -06:00

Author

Owner

@gima commented on GitHub (Jul 4, 2017):

$ firejail --user 
Error: invalid --user command line option

Is this feature still about to be included?

My use-case is this: I would need to overlay/bindmount a file to a directory, to which my user has no write access. I would need to use sudo to run firejail, but then the jailed executable is run as root and not as my user.

If it matters, the file in question is: /usr/lib/firefox/mozilla.cfg

@gima commented on GitHub (Jul 4, 2017): ~~~ $ firejail --user Error: invalid --user command line option ~~~ Is this feature still about to be included? My use-case is this: I would need to overlay/bindmount a file to a directory, to which my user has no write access. I would need to use sudo to run firejail, but then the jailed executable is run as root and not as my user. *If it matters, the file in question is: /usr/lib/firefox/mozilla.cfg*

gitea-mirror commented

2026-05-05 05:10:15 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 17, 2017):

--user option was removed a long time ago. You would need to update your software.

@netblue30 commented on GitHub (Jul 17, 2017): --user option was removed a long time ago. You would need to update your software.

gitea-mirror commented

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

Author

Owner

@scruloose commented on GitHub (Jan 12, 2021):

Wait, what?

In early 2016 you added the option to have Firejail seamlessly switch to another user (when called as root via sudo, naturally) so users could seamlessly combine sandboxing and Linux account separation to suit their use-case… but by a year and a half later it had been "removed a long time ago"?

What did I miss? Did this blow up in somebody's face?

I ask because I would really like that functionality. Being able to run graphical programs, sandboxed and as an entirely different Linux user, but exporting the window to my existing desktop? That would be super helpful. So if it was removed due to factors that can reasonably be resolved, I would ask about re-opening this issue — or I could start a new one; whatever's convenient for you. But if it's more like "Yeah we tried that and the answer is no", then I won't bother.

What do you think?

@scruloose commented on GitHub (Jan 12, 2021): Wait, what? In early 2016 you added the option to have Firejail seamlessly switch to another user (when called as root via sudo, naturally) so users could seamlessly combine sandboxing and Linux account separation to suit their use-case… but by a year and a half later it had been "removed a long time ago"? What did I miss? Did this blow up in somebody's face? I ask because I would *really* like that functionality. Being able to run graphical programs, sandboxed **and** as an entirely different Linux user, but exporting the window to my existing desktop? That would be super helpful. So if it was removed due to factors that can reasonably be resolved, I would ask about re-opening this issue — or I could start a new one; whatever's convenient for you. But if it's more like "Yeah we tried that and the answer is no", then I won't bother. What do you think?

gitea-mirror referenced this issue

2026-05-05 05:26:46 -06:00

[GH-ISSUE #359] firefox: program is automatically started outside of firejail (KDE Plasma) #256

Rows
Columns

[GH-ISSUE #208] option to change user #147