[GH-ISSUE #639] allow empty `--protocol=` list

gitea-mirror commented

2026-05-05 05:52:27 -06:00

Owner

Originally created by @vn971 on GitHub (Jul 17, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/639

Could an empty protocol list be allowed for firejail?
Like this: firejail --noprofile --protocol=
I think it may make sense in some scenarions. If it's not too difficult, please add such an ability?

(Sorry, I don't feel myself confident with C, therefore I can only raise issues & make some tests.. No code changes since I'd probably leak something or worse.)

Relates to:

#6612

Originally created by @vn971 on GitHub (Jul 17, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/639 Could an empty protocol list be allowed for firejail? Like this: `firejail --noprofile --protocol=` I think it may make sense in some scenarions. If it's not too difficult, please add such an ability? (Sorry, I don't feel myself confident with C, therefore I can only raise issues & make some tests.. No code changes since I'd probably leak something or worse.) Relates to: * #6612

gitea-mirror added the

enhancement

label 2026-05-05 05:52:27 -06:00

gitea-mirror commented

2026-05-05 05:52:32 -06:00

Author

Owner

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

I'll bring a fix in this week, thanks!

@netblue30 commented on GitHub (Jul 18, 2016): I'll bring a fix in this week, thanks!

gitea-mirror commented

2026-05-05 05:52:34 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jul 18, 2016):

I'm afraid I'm in the dark here (which is my fault) and I can't quite figure out what this would accomplish. Would --protocol= be the same as --protocol=* i.e. would it allow all protocols (unix, inet, inet6...)? In which case I would suggest either --protocol or (preferably) --protocol=all as the syntax. To me at any rate, --protocol= looks like it's missing an argument on the end. 😃

Or would it deny access to any protocols? In which case, why use it? Wouldn't the absence of the protocol filter, in and of itself deny access to the filtered protocols?

Or am I missing the point entirely?

Like I said, I don't mean to indicate that I think this is a bad idea in any way; I just can't quite figure out what it does.

@Fred-Barclay commented on GitHub (Jul 18, 2016): I'm afraid I'm in the dark here (which is my fault) and I can't quite figure out what this would accomplish. Would `--protocol=` be the same as `--protocol=*` i.e. would it allow **all** protocols (unix, inet, inet6...)? In which case I would suggest either `--protocol` or (preferably) `--protocol=all` as the syntax. To me at any rate, `--protocol=` looks like it's missing an argument on the end. :smiley: Or would it deny access to any protocols? In which case, why use it? Wouldn't the absence of the protocol filter, in and of itself deny access to the filtered protocols? Or am I missing the point entirely? Like I said, I don't mean to indicate that I think this is a bad idea in any way; I just can't quite figure out what it does.

gitea-mirror commented

2026-05-05 05:52:36 -06:00

Author

Owner

@vn971 commented on GitHub (Jul 18, 2016):

Hi @Fred-Barclay, by --protocol= I mean an empty set of allowed protocols. Same as an empty set in Math, or [] as empty arrays in programming.

An empty protocol list means the application cannot use unix sockets, inet interfaces and so on. But it still has access to the filesystem, so it can be a perfectly fine CLI/terminal program.

I guess @netblue30 will decide for naming. --protocol=none could work for some users. I'm perfectly fine with --protocol= because it matches my expectations as a programmer.

@vn971 commented on GitHub (Jul 18, 2016): Hi @Fred-Barclay, by `--protocol=` I mean an empty set of allowed protocols. Same as an empty set in Math, or `[]` as empty arrays in programming. An empty protocol list means the application cannot use unix sockets, inet interfaces and so on. But it still has access to the filesystem, so it can be a perfectly fine CLI/terminal program. I guess @netblue30 will decide for naming. `--protocol=none` could work for some users. I'm perfectly fine with `--protocol=` because it matches my expectations as a programmer.

gitea-mirror commented

2026-05-05 05:52:38 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jul 18, 2016):

Thanks @vn971
Like you, I'm not very confident with C (though I'm practising!) so I'm not really able to dig into the source code to understand these things. 😉
What would be the difference between this (which seems to basically be --protocol=none, am I correct?) and simply not having a protocol filter at all? Wouldn't the lack of a protocol argument deny access to the unix sockets, inet interfaces, and so on?

@Fred-Barclay commented on GitHub (Jul 18, 2016): Thanks @vn971 Like you, I'm not very confident with C (though I'm practising!) so I'm not really able to dig into the source code to understand these things. :wink: What would be the difference between this (which seems to basically be `--protocol=none`, am I correct?) and simply not having a protocol filter at all? Wouldn't the lack of a protocol argument deny access to the unix sockets, inet interfaces, and so on?

gitea-mirror commented

2026-05-05 05:52:40 -06:00

Author

Owner

@vn971 commented on GitHub (Jul 18, 2016):

@Fred-Barclay I think it can be the whitelist/blacklist story that is confusing you. The --protocol directive is whitelist, not blacklist. And the absence of --protocol means to allow everything there is. If you think about it, it really is a little bit strange (at least semantically). --protocol= and the absence of a --protocol directive having the opposite meaning.

It's probably because of the history of firejail and that it tries to be "simple" for end users, therefore favoring "blacklisting" instead of "whitelisting". So adding new directives makes the container boundaries stronger, and some of the directives are whitelist-like.

@vn971 commented on GitHub (Jul 18, 2016): @Fred-Barclay I think it can be the whitelist/blacklist story that is confusing you. The `--protocol` directive is _whitelist_, not blacklist. And the absence of `--protocol` means to allow everything there is. If you think about it, it really is a little bit strange (at least semantically). `--protocol=` and the absence of a `--protocol` directive having the opposite meaning. It's probably because of the history of firejail and that it tries to be "simple" for end users, therefore favoring "blacklisting" instead of "whitelisting". So adding new directives makes the container boundaries stronger, and some of the _directives_ are whitelist-like.

gitea-mirror commented

2026-05-05 05:52:43 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jul 19, 2016):

Aha, that does make more sense! Thanks, mate.

In that case, might I suggest using the syntax --protocol=none to minimise confusion and make its purpose clear?

@Fred-Barclay commented on GitHub (Jul 19, 2016): Aha, that does make more sense! Thanks, mate. In that case, might I suggest using the syntax `--protocol=none` to minimise confusion and make its purpose clear?

gitea-mirror commented

2026-05-05 05:52:45 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 20, 2016):

Yes, it will be --protocol=none, I'll have a fix in this week.

@netblue30 commented on GitHub (Jul 20, 2016): Yes, it will be --protocol=none, I'll have a fix in this week.

gitea-mirror commented

2026-05-05 05:52:46 -06:00

Author

Owner

@vn971 commented on GitHub (Dec 30, 2016):

@netblue30 ping :)

@vn971 commented on GitHub (Dec 30, 2016): @netblue30 ping :)

gitea-mirror commented

2026-05-05 05:52:48 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

I might try working on this, since I don't think it's in yet.

@chiraag-nataraj commented on GitHub (Aug 19, 2018): I might try working on this, since I don't think it's in yet.

gitea-mirror commented

2026-05-05 05:52:50 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

Oh right...I tried working on this a while back and couldn't really figure out how to safely do it... @netblue30 can you take care of this? 🙂

@chiraag-nataraj commented on GitHub (Aug 19, 2018): Oh right...I tried working on this a while back and couldn't really figure out how to safely do it... @netblue30 can you take care of this? :slightly_smiling_face:

gitea-mirror commented

2026-05-05 05:52:51 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 11, 2021):

protocol unix returns EOPNOTSUPP for every call to socket(2) except for socket(AF_UNIX, ...). Therefore would an empty protocol return EOPNOTSUPP for every call to socket(2) (without exceptions).

The only difference between seccomp socket and an empty protocol is that seccomp defaults to EPERM (and does what ever is specified in seccomp-error-action if set) while protocol always returns EOPNOTSUPP.

I'd suggest to close where as wontfix as the difference is so small and the only use case I can see are cli programs which do not need any sockets.

(In that case update pngquant.profile)

@rusty-snake commented on GitHub (Aug 11, 2021): `protocol unix` returns `EOPNOTSUPP` for every call to `socket(2)` except for `socket(AF_UNIX, ...)`. Therefore would an empty `protocol` return `EOPNOTSUPP` for every call to `socket(2)` (without exceptions). The only difference between `seccomp socket` and an empty `protocol` is that `seccomp` defaults to `EPERM` (and does what ever is specified in `seccomp-error-action` if set) while `protocol` always returns `EOPNOTSUPP`. I'd suggest to close where as wontfix as the difference is so small and the only use case I can see are cli programs which do not need any sockets. (In that case update pngquant.profile)

gitea-mirror referenced this issue

2026-05-05 10:04:51 -06:00

[PR #442] [CLOSED] Proposed #3622

Rows
Columns

[GH-ISSUE #639] allow empty --protocol= list #442

[GH-ISSUE #639] allow empty `--protocol=` list #442