Firefox access to Linux documentation

[d-koc]

On Arch Linux, kernel documentation is provided by the linux-docs package at /usr/lib/modules/$(uname -r)/build/Documentation (currently /usr/lib/modules/6.4.8-arch1-1/build/Documentation). I want to grant access to /usr/lib/modules/*/build/Documentation, but Firejail seems to flat-out refuse access to /usr/lib/modules no matter what. I can access the files fine when running Firefox outside of Firejail.

This is probably a result of my misunderstanding how exactly Firejail's access control system works, but I cannot for the life of me figure this out.

Firejail version: 0.9.72
Distro: Arch Linux
I have tried running with --noprofile

(please let me know if this question should be somewhere else, thanks!)

Edit: Added info suggested by CONTRIBUTING.md

[kmk3]

On Arch Linux, kernel documentation is provided by the linux-docs package
at /usr/lib/modules/$(uname -r)/build/Documentation (currently
/usr/lib/modules/6.4.8-arch1-1/build/Documentation). I want to grant access
to /usr/lib/modules/*/build/Documentation, but Firejail seems to flat-out
refuse access to /usr/lib/modules no matter what. I can access the files
fine when running Firefox outside of Firejail.

Good catch.

It seems that blocking access to /usr/lib/modules is hardcoded in the code, as
it's unlikely that any program will need direct access to the kernel module
files:

• firejail/src/firejail/fs.c

  Line 777 in 9f64899

  disable_file(BLACKLIST_FILE, "/lib/modules");

I think it might make more sense to put the documentation in /usr/share/doc
rather than in /usr/lib, as these are not architecture-specific files.

I'd suggest proposing this to the maintainer of linux-docs.

Note that linux-docs even already provides a symlink in /usr/share/doc that
points to the current location:

/usr/share/doc/linux -> ../../lib/modules/$(uname -r)/build/Documentation

[d-koc]

Wow, all of my gratitude! I tested rebuilding Arch's Firejail package with the offending line commented out, and it now functions as expected.
A bit miffed honestly as I'd already searched the code for instances of /usr/lib/modules, suspecting that was the case. /lib/modules is just a symlink on Arch so didn't even cross my mind to check.

Thanks for the suggestion to take it up with the maintainer. I don't know enough about the standard filesystem hierarchy to comment on whether it's the right thing to do, but it being hardcoded in Firejail doesn't feel right to me (isn't that the purpose of the supplied profile files?).

[kmk3]

Wow, all of my gratitude! I tested rebuilding Arch's Firejail package with
the offending line commented out, and it now functions as expected. A bit
miffed honestly as I'd already searched the code for instances of
/usr/lib/modules, suspecting that was the case. /lib/modules is just a
symlink on Arch so didn't even cross my mind to check.

Glad it worked!

Thanks for the suggestion to take it up with the maintainer. I don't know
enough about the standard filesystem hierarchy to comment on whether it's the
right thing to do

That's alright.

but it being hardcoded in Firejail doesn't feel right to me (isn't that the
purpose of the supplied profile files?).

Yes, but glancing at the code, it doesn't seem to be trivial to fix.

Note that the blacklisting of some paths depend on the options being used, and
that other paths are changed only after certain directories are remounted.
There are also multiple functions/ways that are used for blacklisting paths in
the code.

Looking again at the relevant part, it seems that access to that path can be
allowed with --allow-debuggers:

• firejail/src/firejail/fs.c

  Lines 774 to 780 in 9f64899

  	// remove kernel symbol information
  	if (!arg_allow_debuggers) {
  	disable_file(BLACKLIST_FILE, "/usr/src/linux");
  	disable_file(BLACKLIST_FILE, "/lib/modules");
  	disable_file(BLACKLIST_FILE, "/usr/lib/debug");
  	disable_file(BLACKLIST_FILE, "/boot");
  	}

Though note that it allows access to other important paths as well, so use at
your own risk.