[GH-ISSUE #7070] blink-common: Is `caps.keep sys_admin` necessary?

gitea-mirror commented

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

Owner

Originally created by @cobratbq on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/netblue30/firejail/issues/7070

Sorry for dumping this out-of-the-blue, just close if unwanted. I'm browsing profiles for ideas because I'm writing a new profile, then I find this and wonder if it really necessary, that capability SYS_ADMIN is preserved in blink-common.profile?

bbb9787070/etc/profile-a-l/blink-common.profile (L30)

This seems like overreaching, and I can only imagine the chromium sandbox to be the reason for this. This is buried deep, and affects chromium-based browsers and electron-apps alike.

Description

Security-esque question.

Steps to Reproduce

bbb9787070/etc/profile-a-l/blink-common.profile (L30)

Expected behavior

I would expect SYS_ADMIN to be dropped due to it being quite powerful.

Or, if really necessary, maybe makes sense to add a comment stating why it is necessary(?)

Actual behavior

It keeps SYS_ADMIN and is buried quite deep, impacting chromium and electron apps alike.

Behavior without a profile

N/A

Originally created by @cobratbq on GitHub (Feb 19, 2026). Original GitHub issue: https://github.com/netblue30/firejail/issues/7070 Sorry for dumping this out-of-the-blue, just close if unwanted. I'm browsing profiles for ideas because I'm writing a new profile, then I find this and wonder if it really necessary, that capability `SYS_ADMIN` is preserved in `blink-common.profile`? https://github.com/netblue30/firejail/blob/bbb9787070d915390dbfb6d470898c88d0f009c4/etc/profile-a-l/blink-common.profile#L30 This seems like overreaching, and I can only imagine the chromium sandbox to be the reason for this. This is buried deep, and affects chromium-based browsers and electron-apps alike. ### Description Security-esque question. ### Steps to Reproduce https://github.com/netblue30/firejail/blob/bbb9787070d915390dbfb6d470898c88d0f009c4/etc/profile-a-l/blink-common.profile#L30 ### Expected behavior I would expect `SYS_ADMIN` to be dropped due to it being quite powerful. Or, if really necessary, maybe makes sense to add a comment stating _why_ it is necessary(?) ### Actual behavior It keeps `SYS_ADMIN` and is buried quite deep, impacting chromium and electron apps alike. ### Behavior without a profile N/A

gitea-mirror added the

help wanted

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

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Feb 19, 2026):

I checked on Debian trixie, and when removing CAP_SYS_ADMIN, the sandbox seems to work just fine. From the git blame report, it seems to trace back to a former chromium-sandbox.profile.

Now, without CAP_SYS_ADMIN (removed from blink-common.profile), if I run chrome://sandbox I get everything but non-broker-ptrace, but I have ptrace_scope restricted in sysctl. (I did use --ignore=apparmor, but Debian's apparmor profile seems to screw up without using /usr/bin/firejail too.)

--debug reports: set caps filter 40000.

Someone with more knowledge should verify, but I think sys_admin can just be removed from the profile. It seems to create an unnecessarily large hole in restrictions.

@cobratbq commented on GitHub (Feb 19, 2026): I checked on Debian trixie, and when removing `CAP_SYS_ADMIN`, the sandbox seems to work just fine. From the `git blame` report, it seems to trace back to a former `chromium-sandbox.profile`. Now, without `CAP_SYS_ADMIN` (removed from `blink-common.profile`), if I run `chrome://sandbox` I get everything but non-broker-ptrace, but I have `ptrace_scope` restricted in sysctl. (I did use `--ignore=apparmor`, but Debian's apparmor profile seems to screw up without using `/usr/bin/firejail` too.) `--debug` reports: `set caps filter 40000`. Someone with more knowledge should verify, but I think `sys_admin` can just be removed from the profile. It seems to create an unnecessarily large hole in restrictions.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 20, 2026):

I checked on Debian trixie, and when removing CAP_SYS_ADMIN, the sandbox
seems to work just fine. From the git blame report, it seems to trace back
to a former chromium-sandbox.profile.

It looks like it was added in the following commit:

021607388 ("add caps.keep to chrome/chromium", 2017-05-22)

Now, without CAP_SYS_ADMIN (removed from blink-common.profile), if I run
chrome://sandbox I get everything but non-broker-ptrace, but I have
ptrace_scope restricted in sysctl. (I did use --ignore=apparmor, but
Debian's apparmor profile seems to screw up without using /usr/bin/firejail
too.)

--debug reports: set caps filter 40000.

Someone with more knowledge should verify, but I think sys_admin can just
be removed from the profile. It seems to create an unnecessarily large hole
in restrictions.

The main issue is that what chromium uses might depend on multiple system-level
things, like apparmor and ptrace that you mentioned and potentially also
unprivileged user namespaces.

In the sense that if something is not available, it might fall back to
trying to increase privileges.

It would be good to check the chromium source code to see what exactly it uses
this capability for and under what conditions, to see what would be affected if
the capability is removed.

Same for sys_chroot.

@kmk3 commented on GitHub (Feb 20, 2026): > I checked on Debian trixie, and when removing `CAP_SYS_ADMIN`, the sandbox > seems to work just fine. From the `git blame` report, it seems to trace back > to a former `chromium-sandbox.profile`. It looks like it was added in the following commit: * 021607388 ("add caps.keep to chrome/chromium", 2017-05-22) > Now, without `CAP_SYS_ADMIN` (removed from `blink-common.profile`), if I run > `chrome://sandbox` I get everything but non-broker-ptrace, but I have > `ptrace_scope` restricted in sysctl. (I did use `--ignore=apparmor`, but > Debian's apparmor profile seems to screw up without using `/usr/bin/firejail` > too.) > > `--debug` reports: `set caps filter 40000`. > > Someone with more knowledge should verify, but I think `sys_admin` can just > be removed from the profile. It seems to create an unnecessarily large hole > in restrictions. The main issue is that what chromium uses might depend on multiple system-level things, like apparmor and ptrace that you mentioned and potentially also unprivileged user namespaces. In the sense that if something is not available, it might fall back to trying to increase privileges. It would be good to check the chromium source code to see what exactly it uses this capability for and under what conditions, to see what would be affected if the capability is removed. Same for `sys_chroot`.

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Feb 20, 2026):

Wouldn't it reflect this in chrome://sandbox overview? (It effectively shows everything green.)

I wanted to ask the above, but then I received an update which prevents Debian's chromium from running completely. So I am not sure how to interpret previous results.

I was thinking of adding sys_ptrace as ptrace is known to be used, and may be of influence depending on configured kernel.yama.ptrace_scope setting (1 for parent-process, 2 for ptrace-capability, 3 to disable completely).

I would think unprivileged user-namespaces don't require a capability, but then there are some restrictions w.r.t. apparmor and sysctl settings that prevent certain combinations. I can't speak about anything else yet.

@cobratbq commented on GitHub (Feb 20, 2026): > Wouldn't it reflect this in `chrome://sandbox` overview? (It effectively shows everything green.) I wanted to ask the above, but then I received an update which prevents Debian's chromium from running completely. So I am not sure how to interpret previous results. I was thinking of adding `sys_ptrace` as ptrace is known to be used, and may be of influence depending on configured `kernel.yama.ptrace_scope` setting (`1` for parent-process, `2` for ptrace-capability, `3` to disable completely). I would think _unprivileged user-namespaces_ don't require a capability, but then there are some restrictions w.r.t. apparmor and sysctl settings that prevent certain combinations. I can't speak about anything else yet.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 20, 2026):

I would think unprivileged user-namespaces don't require a capability, but
then there are some restrictions w.r.t. apparmor and sysctl settings that
prevent certain combinations. I can't speak about anything else yet.

To clarify, I mean in the sense that unprivileged user namespaces might be
disabled system-wide (like with ptrace).

In which case the program might see that it is unavailable, raise privileges
and try again or just raise privileges and do it in another way entirely (such
as by bind-mounting paths, etc).

@kmk3 commented on GitHub (Feb 20, 2026): > I would think _unprivileged user-namespaces_ don't require a capability, but > then there are some restrictions w.r.t. apparmor and sysctl settings that > prevent certain combinations. I can't speak about anything else yet. To clarify, I mean in the sense that unprivileged user namespaces might be disabled system-wide (like with ptrace). In which case the program might see that it is unavailable, raise privileges and try again or just raise privileges and do it in another way entirely (such as by bind-mounting paths, etc).

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Feb 20, 2026):

I wanted to ask the above, but then I received an update which prevents Debian's chromium from running completely. So I am not sure how to interpret previous results.

This is incorrect. I forgot to disable AppArmor, and AppArmor was still blocking it because of user-namespaces being unavailable.

Facts:

chrome://sandbox reports effective results of acquired level of sandboxing (and claims "You are adequately sandboxed.", on Debian)
firejail --debug demonstrates changing capabilities in "Set caps filter 40000". (Without sys_admin, with only sys_chroot kept.)
(unprivileged) user-namespaces are hard requirement; fails if:
- blocked through AppArmor (audit reports denied="userns_create"); or through
- --restrict-namespaces=user
ptrace is optional (with kernel.yama.ptrace_scope=2 reports same sandboxing results whether whether or not sys_ptrace syscall preserved. (I need to try with value 1. Value 3 always blocks.)
sys_chroot also does not seem to be required. (Effective sandboxing results do not change when removed.)
AppArmor should be out of scope: firejail depends on a correct apparmor profile or, conversely, allows disabling AppArmor (--ignore=apparmor) in case there isn't. It is out of your control anyways.
Restricting namespaces one-by-one:
- Critical (not starting): net, pid, user
- Sandbox not affected: cgroup, ipc, mnt, time, uts

I understand your position on checking the sources. However, I wonder if we can reasonably derive what we need to know from behavior. I have removed preservation of any capabilities. It doesn't complain; it starts. The quality of the sandbox is not affected in a reported/detected way. Except, in case of mentioned namespace-restrictions, the application refuses to start if absent through whichever means.

@cobratbq commented on GitHub (Feb 20, 2026): > I wanted to ask the above, but then I received an update which prevents Debian's chromium from running completely. So I am not sure how to interpret previous results. This is incorrect. I forgot to disable AppArmor, and AppArmor was still blocking it because of user-namespaces being unavailable. Facts: - `chrome://sandbox` reports effective results of acquired level of sandboxing (and claims "You are adequately sandboxed.", on Debian) - `firejail --debug` demonstrates changing capabilities in "_Set caps filter 40000_". (Without `sys_admin`, with only `sys_chroot` kept.) - (unprivileged) user-namespaces are hard requirement; fails if: - blocked through AppArmor (audit reports `denied="userns_create"`); or through - `--restrict-namespaces=user` - ptrace is optional (with `kernel.yama.ptrace_scope=2` reports same sandboxing results whether whether or not `sys_ptrace` syscall preserved. (I need to try with value `1`. Value `3` always blocks.) - `sys_chroot` also does not seem to be required. (Effective sandboxing results do not change when removed.) - AppArmor should be out of scope: `firejail` depends on a correct apparmor profile or, conversely, allows disabling AppArmor (`--ignore=apparmor`) in case there isn't. It is out of your control anyways. - Restricting namespaces one-by-one: - Critical (not starting): `net`, `pid`, `user` - Sandbox not affected: `cgroup`, `ipc`, `mnt`, `time`, `uts` I understand your position on checking the sources. However, I wonder if we can reasonably derive what we need to know from behavior. I have removed preservation of any capabilities. It doesn't complain; it starts. The quality of the sandbox is not affected in a reported/detected way. Except, in case of mentioned namespace-restrictions, the application refuses to start if absent through whichever means.

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Feb 21, 2026):

With user-namespaces disabled via sysctl user.max_user_namespaces=0, chromium is forced to look for chrome-sandbox (setuid), and then requires CAP_SYS_ADMIN. It fails to start if chrome-sandbox is not available. I have not found another capability that accomplishes the same thing. (I.e. chromium behaves differently with user.max_user_namespaces == 0.) chrome://sandbox marks the SUID-sandbox as "yellow", instead of green, hinting at inferior solution.

In my understanding, it is not possible to set separate permissions/capabilities on a different executable? I.e. they're managed on the "live process".

So, I see possibilities that I haven't explored:

Are AppArmor-rules that grant CAP_SYS_ADMIN (or otherwise possibility to create namespaces) to chrome-sandbox? (Yes, you cannot rely on this, strictly speaking, as I stated myself.)
Can something be done with NONEWPRIVS to conditionally grant CAP_SYS_ADMIN specifically to chrome-sandbox? (Also explicitly mentioned for --nonewprivs parameter.)
It is possible to express a conditional for user-namespaces-available, which I don't think exists.

If user-namespaces are available, then caps.drop all is possible/viable without affecting sandboxing effectiveness, according to chrome://sandbox.

@cobratbq commented on GitHub (Feb 21, 2026): With user-namespaces disabled via `sysctl user.max_user_namespaces=0`, chromium is forced to look for `chrome-sandbox` (setuid), and then requires `CAP_SYS_ADMIN`. It fails to start if `chrome-sandbox` is not available. I have not found another capability that accomplishes the same thing. (I.e. chromium behaves differently with `user.max_user_namespaces == 0`.) `chrome://sandbox` marks the SUID-sandbox as "yellow", instead of green, hinting at inferior solution. In my understanding, it is not possible to set separate permissions/capabilities on a different executable? I.e. they're managed on the "live process". So, I see possibilities that I haven't explored: - Are AppArmor-rules that grant `CAP_SYS_ADMIN` (or otherwise possibility to create namespaces) to `chrome-sandbox`? (Yes, you cannot rely on this, strictly speaking, as I stated myself.) - Can something be done with `NONEWPRIVS` to conditionally grant `CAP_SYS_ADMIN` specifically to `chrome-sandbox`? (Also explicitly mentioned for `--nonewprivs` parameter.) - It is possible to express a conditional for `user-namespaces-available`, which I don't think exists. If _user-namespaces_ are available, then `caps.drop all` is possible/viable without affecting sandboxing effectiveness, according to `chrome://sandbox`.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 21, 2026):

chrome://sandbox reports effective results of acquired level of
sandboxing (and claims "You are adequately sandboxed.", on Debian)

It's nice to see that chrome://sandbox makes it clear enough when it's
working vs not.

With user-namespaces disabled via sysctl user.max_user_namespaces=0,
chromium is forced to look for chrome-sandbox (setuid), and then requires
CAP_SYS_ADMIN. It fails to start if chrome-sandbox is not available.

This is more or less what I expected.

Thanks for all the testing.

Maybe a conditional could be added for unprivileged user namespaces.

Example:

?HAS_UNPRIVILEGED_USER_NS:  caps.drop all
?!HAS_UNPRIVILEGED_USER_NS: caps.keep sys_admin,sys_chroot

The negation part (?!) does not exist currently, but it could easily be added.

Also, note that any change to blink-common would affect all blink-based
programs, including electron-based ones, not just chromium and derivative
browsers.

@rusty-snake

Thoughts?

@kmk3 commented on GitHub (Feb 21, 2026): > * `chrome://sandbox` reports effective results of acquired level of > sandboxing (and claims "You are adequately sandboxed.", on Debian) It's nice to see that `chrome://sandbox` makes it clear enough when it's working vs not. > With user-namespaces disabled via `sysctl user.max_user_namespaces=0`, > chromium is forced to look for `chrome-sandbox` (setuid), and then requires > `CAP_SYS_ADMIN`. It fails to start if `chrome-sandbox` is not available. This is more or less what I expected. Thanks for all the testing. Maybe a conditional could be added for unprivileged user namespaces. Example: ``` ?HAS_UNPRIVILEGED_USER_NS: caps.drop all ?!HAS_UNPRIVILEGED_USER_NS: caps.keep sys_admin,sys_chroot ``` The negation part (`?!`) does not exist currently, but it could easily be added. Also, note that any change to blink-common would affect all blink-based programs, including electron-based ones, not just chromium and derivative browsers. @rusty-snake Thoughts?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Feb 21, 2026):

8ffeed77da/etc/profile-a-l/blink-common.profile (L24-L27)

@rusty-snake commented on GitHub (Feb 21, 2026): https://github.com/netblue30/firejail/blob/8ffeed77da1731120980e53157e5d47ca8667f7a/etc/profile-a-l/blink-common.profile#L24-L27

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Feb 21, 2026):

So all what you need is

?HAS_UNPRIVILEGED_USER_NS: include blink-common-hardened.inc.profile

@rusty-snake commented on GitHub (Feb 21, 2026): So all what you need is ``` ?HAS_UNPRIVILEGED_USER_NS: include blink-common-hardened.inc.profile ```

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 21, 2026):

So all what you need is

?HAS_UNPRIVILEGED_USER_NS: include blink-common-hardened.inc.profile

That would be nice, but unfortunately it looks like conditionals do not work
for include:

From man firejail-profile:

       ?CONDITIONAL: profile line
              Conditionally add profile line.

              Example: "?HAS_APPIMAGE: whitelist ${HOME}/special/appimage/dir"

              [...]

              The profile line may be any profile line that you would normally
              use in a profile except for "quiet" and "include" lines.

@kmk3 commented on GitHub (Feb 21, 2026): > So all what you need is > > ``` > ?HAS_UNPRIVILEGED_USER_NS: include blink-common-hardened.inc.profile > ``` That would be nice, but unfortunately it looks like conditionals do not work for `include`: From `man firejail-profile`: ``` ?CONDITIONAL: profile line Conditionally add profile line. Example: "?HAS_APPIMAGE: whitelist ${HOME}/special/appimage/dir" [...] The profile line may be any profile line that you would normally use in a profile except for "quiet" and "include" lines. ```

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Feb 21, 2026):

Yeah, would need to inline it. However the point was more on not need ?! and being more than caps.

@rusty-snake commented on GitHub (Feb 21, 2026): Yeah, would need to inline it. However the point was more on not need `?!` and being more than caps.

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Feb 21, 2026):

It's nice to see that chrome://sandbox makes it clear enough when it's working vs not.

Layer 1 Sandbox: Namespace (green), or SUID (yellow, this is chrome-sandbox), or None (red)
PID namespaces: yes/no
Network namespaces: yes/no
Seccomp-BPF sandbox: yes/no
Seccomp-BPF sandbox supports TSYNC: yes/no
Ptrace Protection with Yama LSM (Broker): yes/no
Ptrace Protection with Yama LSM (Non-broker): yes/no

Fyi, I'm guessing some are binary yes/no, because I can run with --no-sandbox and see everything disabled, but haven't tried all permutations for this listing.

Or, all disabled and all red (None, no, no, ...) when started with --no-sandbox.

@cobratbq commented on GitHub (Feb 21, 2026): > It's nice to see that chrome://sandbox makes it clear enough when it's working vs not. Layer 1 Sandbox: `Namespace` (green), or `SUID` (yellow, this is `chrome-sandbox`), or `None` (red) PID namespaces: `yes`/`no` Network namespaces: `yes`/`no` Seccomp-BPF sandbox: `yes`/`no` Seccomp-BPF sandbox supports TSYNC: `yes`/`no` Ptrace Protection with Yama LSM (Broker): `yes`/`no` Ptrace Protection with Yama LSM (Non-broker): `yes`/`no` > Fyi, I'm guessing some are binary yes/no, because I can run with `--no-sandbox` and see everything disabled, but haven't tried all permutations for this listing. Or, all disabled and all red (None, no, no, ...) when started with `--no-sandbox`.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 25, 2026):

Yeah, would need to inline it. However the point was more on not need ?!
and being more than caps.

I agree that conditionals + include would be nicer (and less verbose), but
making conditionals work with include in the code seems considerably more
complicated than just adding ?!.

(At least considering a previous experience of trying to add
profile_add("include ...") to some part of the code, seeing that it does not
work, trying to make profile_add() work with include, then giving up after
many hours.)

Thoughts on adding ?! for the time being?

It might be useful for other conditionals as well (I vaguely remember wanting
to use a negated conditional before).

@kmk3 commented on GitHub (Feb 25, 2026): > Yeah, would need to inline it. However the point was more on not need `?!` > and being more than caps. I agree that conditionals + `include` would be nicer (and less verbose), but making conditionals work with `include` in the code seems considerably more complicated than just adding `?!`. (At least considering a previous experience of trying to add `profile_add("include ...")` to some part of the code, seeing that it does not work, trying to make `profile_add()` work with `include`, then giving up after many hours.) Thoughts on adding `?!` for the time being? It might be useful for other conditionals as well (I vaguely remember wanting to use a negated conditional before).

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Feb 25, 2026):

Thoughts on adding ?! for the time being?

Four lines with ? or four negated lines with ?!. I see difference.

@rusty-snake commented on GitHub (Feb 25, 2026): > Thoughts on adding ?! for the time being? Four lines with ? or four negated lines with ?!. I see difference.

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Mar 5, 2026):

Also, the boolean for has-user-namespaces should probably be derived from multiple indicators. Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when user.max_user_namespaces = 0.

@cobratbq commented on GitHub (Mar 5, 2026): Also, the boolean for `has-user-namespaces` should probably be derived from multiple indicators. Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when `user.max_user_namespaces = 0`.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 5, 2026):

Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when user.max_user_namespaces = 0.

EPERM vs ENOSPC. I would say they are available if a test-helper can unshare(CLONE_NEWUSER).

@rusty-snake commented on GitHub (Mar 5, 2026): > Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when user.max_user_namespaces = 0. EPERM vs ENOSPC. I would say they are available if a test-helper can `unshare(CLONE_NEWUSER)`.

gitea-mirror commented

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

Author

Owner

@cobratbq commented on GitHub (Apr 10, 2026):

Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when user.max_user_namespaces = 0.

EPERM vs ENOSPC. I would say they are available if a test-helper can unshare(CLONE_NEWUSER).

Yes, and I've ran into this again, and I wonder if firejail needs to support --restrict-namespaces=user:ENOSPC syntax such that it is configurable what "signal" to send when rejecting (user-)namespaces. Considering that at least Chromium behaves differently depending on this response, i.e. if firejail could reject with user:ENOSPC, then Chromium would likely default to chromium-sandbox as fallback. (Firefox shows the same err-message regardless of EPERM or ENOSPC.)

@cobratbq commented on GitHub (Apr 10, 2026): > > Chromium behaves differently when receiving permission-denied on attempt to create namespaces, than it does when user.max_user_namespaces = 0. > > EPERM vs ENOSPC. I would say they are available if a test-helper can `unshare(CLONE_NEWUSER)`. Yes, and I've ran into this again, and I wonder if firejail needs to support `--restrict-namespaces=user:ENOSPC` syntax such that it is configurable what "signal" to send when rejecting (user-)namespaces. Considering that [at least Chromium](<https://github.com/netblue30/firejail/issues/7070#issuecomment-3937415781>) behaves differently depending on this response, i.e. if firejail could reject with `user:ENOSPC`, then Chromium would likely default to `chromium-sandbox` as fallback. (Firefox shows the same err-message regardless of `EPERM` or `ENOSPC`.)

Rows
Columns

[GH-ISSUE #7070] blink-common: Is caps.keep sys_admin necessary? #3476

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

[GH-ISSUE #7070] blink-common: Is `caps.keep sys_admin` necessary? #3476