[GH-ISSUE #2] Minor man page fixes/suggestions

gitea-mirror commented

2026-05-05 04:42:03 -06:00

Owner

Originally created by @boltronics on GitHub (Aug 9, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2

The top of the FIREJAIL-PROFILE(5) and FIREJAIL(1) man pages both say man(5) and man(1) respectively, instead of having the correct name.

Also, I think it's a mistake for the firejail-profile(5) seccomp section to not list the defaults. I assume it's the same as those in --seccomp discussed in firejail(1), but it would be nice if it was explicit and didn't force the user to hunt the list down. I would suggest either duplicating the list, or simply pointing the reader to the firejail(1) --seccomp section.

Originally created by @boltronics on GitHub (Aug 9, 2015). Original GitHub issue: https://github.com/netblue30/firejail/issues/2 The top of the FIREJAIL-PROFILE(5) and FIREJAIL(1) man pages both say man(5) and man(1) respectively, instead of having the correct name. Also, I think it's a mistake for the firejail-profile(5) seccomp section to not list the defaults. I assume it's the same as those in --seccomp discussed in firejail(1), but it would be nice if it was explicit and didn't force the user to hunt the list down. I would suggest either duplicating the list, or simply pointing the reader to the firejail(1) --seccomp section.

gitea-mirror

2026-05-05 04:42:03 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 04:42:12 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 10, 2015):

Also, in firejail-profile(5) you have:

       caps.drop capability,capability,capability
              Whitelist Linux capabilities filter.

which I assume should be:

       caps.keep capability,capability,capability
              Whitelist Linux capabilities filter.

@boltronics commented on GitHub (Aug 10, 2015): Also, in firejail-profile(5) you have: ``` caps.drop capability,capability,capability Whitelist Linux capabilities filter. ``` which I assume should be: ``` caps.keep capability,capability,capability Whitelist Linux capabilities filter. ```

gitea-mirror commented

2026-05-05 04:42:16 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 10, 2015):

One other thing is that it's very unclear how the include arguments work.

The man page simply states:

       Include and comment support:

       include other.profile
              Include other.profile file.

In a Chromium profile, I have the lines:

include /etc/firejail/disable-secret.inc
include /etc/firejail/disable-common.inc chromium

So presumably the chromium argument disables the blacklist ${HOME}/.config/chromium line in disable-common.inc, but it's not clear how this works. Is it a regex? A file glob? It appears that adding the full path (ie. ${HOME}/.config/chromium) doesn't work, which is surprising.

@boltronics commented on GitHub (Aug 10, 2015): One other thing is that it's very unclear how the `include` arguments work. The man page simply states: ``` Include and comment support: include other.profile Include other.profile file. ``` In a Chromium profile, I have the lines: ``` include /etc/firejail/disable-secret.inc include /etc/firejail/disable-common.inc chromium ``` So presumably the `chromium` argument disables the `blacklist ${HOME}/.config/chromium` line in disable-common.inc, but it's not clear how this works. Is it a regex? A file glob? It appears that adding the full path (ie. `${HOME}/.config/chromium`) doesn't work, which is surprising.

gitea-mirror commented

2026-05-05 04:42:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2015):

Thanks, I'll fix them

@netblue30 commented on GitHub (Aug 10, 2015): Thanks, I'll fix them

gitea-mirror commented

2026-05-05 04:42:23 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2015):

Fixed! Let me know if you find anything else.

@netblue30 commented on GitHub (Aug 10, 2015): Fixed! Let me know if you find anything else.

gitea-mirror commented

2026-05-05 04:42:28 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 11, 2015):

No worries. Looks good, but I need to figure out how to package this before I can properly test. Looks like a few debian files are missing (eg. changelog, rules, compat) and the control file is missing the information on creating a source package as well. I've got it mostly building, but still hitting a snag.

I know there is a package for this in Debian sid, so I might reference that for some pointers, and will get back to this when I have time. Otherwise, feel free to close and I can re-open if I notice something's still not quite right. Thanks!

@boltronics commented on GitHub (Aug 11, 2015): No worries. Looks good, but I need to figure out how to package this before I can properly test. Looks like a few debian files are missing (eg. changelog, rules, compat) and the control file is missing the information on creating a source package as well. I've got it mostly building, but still hitting a snag. I know there is a package for this in Debian sid, so I might reference that for some pointers, and will get back to this when I have time. Otherwise, feel free to close and I can re-open if I notice something's still not quite right. Thanks!

gitea-mirror commented

2026-05-05 04:42:30 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 11, 2015):

This is how I build the packages I distribute myself:

$ ./configure --prefix=/usr
$ sudo make deb

@netblue30 commented on GitHub (Aug 11, 2015): This is how I build the packages I distribute myself: $ ./configure --prefix=/usr $ sudo make deb

gitea-mirror commented

2026-05-05 04:42:32 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 11, 2015):

Interesting. I didn't notice that mkdeb.sh file - I wasn't looking for it and didn't expect something like that. I believe dpkg-buildpackage is the recommended way to handle this (it's what is documented in the Debian New Maintainers' Guide, but your script seems to simply rearrange the directory structure and finally calls dpkg-deb -b directly.

Might be worth a read: https://raphaelhertzog.com/2010/12/17/do-not-build-a-debian-package-with-dpkg-b/

Happy to open another issue/feature request if you agree. :)

@boltronics commented on GitHub (Aug 11, 2015): Interesting. I didn't notice that mkdeb.sh file - I wasn't looking for it and didn't expect something like that. I believe dpkg-buildpackage is the recommended way to handle this (it's what is documented in the [Debian New Maintainers' Guide](https://www.debian.org/doc/manuals/maint-guide/build.en.html), but your script seems to simply rearrange the directory structure and finally calls `dpkg-deb -b` directly. Might be worth a read: https://raphaelhertzog.com/2010/12/17/do-not-build-a-debian-package-with-dpkg-b/ Happy to open another issue/feature request if you agree. :)

gitea-mirror commented

2026-05-05 04:42:34 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 11, 2015):

It's not worth it. I hope to get out of the package building soon, Debian guys are taking over the packages.

@netblue30 commented on GitHub (Aug 11, 2015): It's not worth it. I hope to get out of the package building soon, Debian guys are taking over the packages.

gitea-mirror commented

2026-05-05 04:42:35 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 12, 2015):

I hope to get out of the package building soon, Debian guys are taking over the packages.

It's still useful for people that want to build from source. For example, if I'm going to test your changes, I'm going to have to build a package from git, so I'd ideally just run the standard git-buildpackage or dpkg-buildpackage and know what I'm building is safe and compliant. Forcing people to create packages from scratch to use the git sources can be a bit much.

IMO, this is an example of a project that gets packaging right:
http://cdemu.sourceforge.net/debian/

If I find the time, would you accept a pull request?

@boltronics commented on GitHub (Aug 12, 2015): > I hope to get out of the package building soon, Debian guys are taking over the packages. It's still useful for people that want to build from source. For example, if I'm going to test your changes, I'm going to have to build a package from git, so I'd ideally just run the standard git-buildpackage or dpkg-buildpackage and know what I'm building is safe and compliant. Forcing people to create packages from scratch to use the git sources can be a bit much. IMO, this is an example of a project that gets packaging right: http://cdemu.sourceforge.net/debian/ If I find the time, would you accept a pull request?

gitea-mirror commented

2026-05-05 04:42:38 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 12, 2015):

Absolutely! If you send a pull request I'll accept it. Thanks!

@netblue30 commented on GitHub (Aug 12, 2015): Absolutely! If you send a pull request I'll accept it. Thanks!

gitea-mirror referenced this issue

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

[GH-ISSUE #175] using links in sandboxed firefox #121

gitea-mirror referenced this issue

2026-05-05 05:24:09 -06:00