[GH-ISSUE #1964] UID_MIN evaluation at runtime

gitea-mirror commented

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

Owner

Originally created by @reinerh on GitHub (May 29, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1964

Currently UID_MIN is obtained at build time from /etc/login.defs.
This will break for users of binary distributions that don't compile software themselves, because they can't use firejail with users that have a lower UID.

A Debian user reported this problem, as his user has a UID of 256, while the default on the build servers is 1000 (which is not guaranteed; the build server could be configured to have a MIN_UID over 9000).

So instead of hardcoding this, I would suggest to obtain that limit at runtime.

(This might also be the reason in #1963.)

Originally created by @reinerh on GitHub (May 29, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1964 Currently UID_MIN is obtained at build time from /etc/login.defs. This will break for users of binary distributions that don't compile software themselves, because they can't use firejail with users that have a lower UID. A Debian user [reported](https://bugs.debian.org/900337) this problem, as his user has a UID of 256, while the default on the build servers is 1000 (which is not guaranteed; the build server could be configured to have a MIN_UID over 9000). So instead of hardcoding this, I would suggest to obtain that limit at runtime. (This might also be the reason in #1963.)

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@mestia commented on GitHub (May 29, 2018):

What is rationale behind this check for UID_MIN?
Isn't it much better to allow only users defined in the database?

@mestia commented on GitHub (May 29, 2018): What is rationale behind this check for UID_MIN? Isn't it much better to allow only users defined in the database?

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (May 30, 2018):

Will do!

What is rationale behind this check for UID_MIN? Isn't it much better to allow only users defined in the database?

root user is allowed by default, all other system users (numbers below UID_MIN) run the program as is, without any jail.

@netblue30 commented on GitHub (May 30, 2018): Will do! > What is rationale behind this check for UID_MIN? Isn't it much better to allow only users defined in the database? root user is allowed by default, all other system users (numbers below UID_MIN) run the program as is, without any jail.

gitea-mirror commented

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

Author

Owner

@mestia commented on GitHub (May 30, 2018):

Got it now. Thank you for clarification.

@mestia commented on GitHub (May 30, 2018): Got it now. Thank you for clarification.

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Jun 4, 2018):

All set, commit: ac92833652

@netblue30 commented on GitHub (Jun 4, 2018): All set, commit: https://github.com/netblue30/firejail/commit/ac9283365224ed46ab2087c050ae1e2916a0dbf5

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Jun 30, 2018):

@netblue30 can this be closed, or is there a reason why you reopened it?

@reinerh commented on GitHub (Jun 30, 2018): @netblue30 can this be closed, or is there a reason why you reopened it?

gitea-mirror commented

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

Author

Owner

@nyarvin commented on GitHub (Jul 12, 2018):

While the comment in the code (and a comment above) says "all other system users ... run the code as is, without any jail", that's not the effect I see: instead they are blocked from running it, with an error message printed. Which to my mind is probably better than dropping the jail, anyway -- it's dangerous for protections to silently be dropped. So better to change the comment than the behavior. But also, as it stands, system users can't be allowed to run firejail even by adding their names to firejail.users. I'm interested in this because, for historical reasons, my user id lies in the range of "system users"; I could of course change this, but it's never caused problems before. In general, decreeing that no system user can ever use firejail seems rather odd; surely there's a good use or two out there, even if most system user sandboxing is better done via other means. So I recommend, in firejail_user.c, rearranging the code so as to move the check for system users inside the subsequent if statement, so that it only applies when there is no firejail_users file provided. That way if someone does explicitly allow a system user it will work, yet by default they'll still be blocked.

@nyarvin commented on GitHub (Jul 12, 2018): While the comment in the code (and a comment above) says "all other system users ... run the code as is, without any jail", that's not the effect I see: instead they are blocked from running it, with an error message printed. Which to my mind is probably better than dropping the jail, anyway -- it's dangerous for protections to silently be dropped. So better to change the comment than the behavior. But also, as it stands, system users can't be allowed to run firejail even by adding their names to firejail.users. I'm interested in this because, for historical reasons, my user id lies in the range of "system users"; I could of course change this, but it's never caused problems before. In general, decreeing that no system user can ever use firejail seems rather odd; surely there's a good use or two out there, even if most system user sandboxing is better done via other means. So I recommend, in firejail_user.c, rearranging the code so as to move the check for system users inside the subsequent if statement, so that it only applies when there is no firejail_users file provided. That way if someone does explicitly allow a system user it will work, yet by default they'll still be blocked.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Jul 13, 2018):

@netblue30 can you confirm above?

@Vincent43 commented on GitHub (Jul 13, 2018): @netblue30 can you confirm above?

gitea-mirror commented

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

Author

Owner

@JulienPalard commented on GitHub (Jul 16, 2018):

But also, as it stands, system users can't be allowed to run firejail even by adding their names to firejail.users.

I can confirm, and I'm in the same position, I'm using firejail from a system user (ID 999), and even by adding it to the firejail.users it won't be allowed to use firejail, which if find sad.

@JulienPalard commented on GitHub (Jul 16, 2018): > But also, as it stands, system users can't be allowed to run firejail even by adding their names to firejail.users. I can confirm, and I'm in the same position, I'm using firejail from a system user (ID 999), and even by adding it to the firejail.users it won't be allowed to use firejail, which if find sad.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Jul 16, 2018):

@nyarvin @JulienPalard I assume you are running latest firejail compiled from github , right?

@Vincent43 commented on GitHub (Jul 16, 2018): @nyarvin @JulienPalard I assume you are running latest firejail compiled from github , right?

gitea-mirror commented

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

Author

Owner

@nyarvin commented on GitHub (Jul 17, 2018):

My comments were based on the 0.9.54 release. But using the github browser to look at the current firejail_user_check() code in src/lib/firejail_user.c, I don't see any changes, at least not any that would modify my comments.

@nyarvin commented on GitHub (Jul 17, 2018): My comments were based on the 0.9.54 release. But using the github browser to look at the current firejail_user_check() code in src/lib/firejail_user.c, I don't see any changes, at least not any that would modify my comments.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Jul 17, 2018):

@nyarvin but the commit which is supposed to enable runtime checking is from June 4 while firejail 0.9.54 release is from May 16.

Please test latest git snapshot.

@Vincent43 commented on GitHub (Jul 17, 2018): @nyarvin but the commit which is supposed to enable runtime checking is from [June 4](https://github.com/netblue30/firejail/commit/ac9283365224ed46ab2087c050ae1e2916a0dbf5) while firejail 0.9.54 release is from [May 16](https://github.com/netblue30/firejail/releases/tag/0.9.54). Please test latest git snapshot.

gitea-mirror commented

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

Author

Owner

@nyarvin commented on GitHub (Jul 17, 2018):

Runtime checking isn't an issue for me; I was commenting on other aspects of this. (Which maybe should be moved to a separate issue; if so, apologies for putting them here.)

@nyarvin commented on GitHub (Jul 17, 2018): Runtime checking isn't an issue for me; I was commenting on other aspects of this. (Which maybe should be moved to a separate issue; if so, apologies for putting them here.)

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Jul 17, 2018):

@nyarvin ok, please open new issue then.

@Vincent43 commented on GitHub (Jul 17, 2018): @nyarvin ok, please open new issue then.

gitea-mirror referenced this issue

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

[GH-ISSUE #4206] [NOT SURE IF BUG] multiple instances of same application started via "firejail --private $PROG" not isolated but share data #2579

Rows
Columns

[GH-ISSUE #1964] UID_MIN evaluation at runtime #1319