firejail starting with systemd and different user well, but inside shell not.

[osevan]

I found since months a bug in firejail.

Im starting firejail with systemd and everything is working.

But when I try to start

sudo -u nginx -H firejail --debug /usr/sbin/nginx &

Firejail complains my server.local and globals.local file

Error: cannot access profile file : server.local

But with same profile and user settings with systemd firejail running well.

Thanks and

Best regards

[glitsj16]

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

[osevan]

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

You mean moving *.local files to /etc/firejail helps?

Because im creating user without homedirectory and setting shell to /bin/false.

Even when I set shell to /bin/bash or sh this happens

I have shell none in config.

And back to systemd

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing,

I have setupped my own systemd file and I didn't planted security cgroup and cname stuff by systemd - so the answer is clearly no.

[osevan]

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Firejail installing these files everytime in

/usr/local/etc/firejail

[glitsj16]

You mean moving *.local files to /etc/firejail helps?

I cannot be certain this would help, because I don't know the specifics on how you've created/limited the nginx user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail.

So yes, give that a try. You should see straight-away if that fixes this or not.

Firejail installing these files everytime in /usr/local/etc/firejail

Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a 0.9.70 release that has a fix for CVE-2022-31214. Time to upgrade your Firejail!

[osevan]

You mean moving *.local files to /etc/firejail helps?

I cannot be certain this would help, because I don't know the specifics on how you've created/limited the nginx user on your end. I don't actually need to know that, but it makes sense that Firejail would complain if it cannot find these local overrides in /etc/firejail and doesn't have access to e.g. /home/osevan/.config/firejail.

So yes, give that a try. You should see straight-away if that fixes this or not.

Firejail installing these files everytime in /usr/local/etc/firejail

Hang on. Seeing /usr/local/etc/firejail in this context makes me wonder about your Firejail setup. From the screenshots I assume this is a Debian OS, correct? And Firejail reports being at version 0.9.69. Do you manually compile Firejail instead of using a repo package? Just in case you missed it: there's been a 0.9.70 release that has a fix for CVE-2022-31214. Time to upgrade your Firejail!

Im arch user and my vm running debian bullseye.

Im always compile manualy software

You think upgrading will help me?

[glitsj16]

Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

[osevan]

Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem?

And --prefix=/usr flag installing profiles automaticaly to /etc/firejail correctly and binary files in /usr/bin/ ?

[kmk3]

@osevan commented on Jun 16:

Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem?

And --prefix=/usr flag installing profiles automaticaly to /etc/firejail correctly and binary files in /usr/bin/ ?

Regardless of whether it solves this problem, reducing system deviations helps with debugging.

On Debian you can easily build a firejail .deb package from source and install it:

# Note: Running ./configure before `make deb` will probably not be needed in
# the next release
# Edit: Ignore the above comment; mkdeb.sh still depends on config.mk (see
# #5219)
./configure
make deb
dpkg -i firejail*.deb

This is basically how the official Debian package is built (and make deb uses --prefix=/usr internally), so your setup will likely be more similar to the ones of other Debian users.

In general, it's better to install things through the system package manager, as it tracks which files belong to the package and so it can better ensure a cleaner upgrade/removal and it can warn you when there are conflicts with the configuration files in /etc.

[osevan]

@osevan commented on Jun 16:

Im arch user and my vm running debian bullseye. Im always compile manualy software You think upgrading will help me?

Thanks, that explains things. I still think you need to try moving those local overrides to /etc/firejail or /usr/local/etc/firejail in the VM to see if that fixes things. Technically the upgrade won't help you there IMO. But running a Firejail version that's known to be vulnerable for a specific CVE isn't the safest thing to do. Whenever you decide to do such a manual build of 0.9.70, you might want to consider adding the --prefix=/usr option to the configure command. Again, it's not strictly needed, but it will get your 'regular' and 'VM' versions on par, what simplifies things whenever you're faced with something like this current issue. Call it 'recommended'.

You mean moving /usr/local/etc/firejail/* to /etc/firejail/ fix my problem? And --prefix=/usr flag installing profiles automaticaly to /etc/firejail correctly and binary files in /usr/bin/ ?

Regardless of whether it solves this problem, reducing system deviations helps with debugging.

On Debian you can easily build a firejail .deb package from source and install it:

# Note: Running ./configure before `make deb` will probably not be needed in
# the next release
./configure
make deb
dpkg -i firejail*.deb

This is basically how the official Debian package is built (and make deb uses --prefix=/usr internally), so your setup will likely be more similar to the ones of other Debian users.

In general, it's better to install things through the system package manager, as it tracks which files belong to the package and so it can better ensure a cleaner upgrade/removal and it can warn you when there are conflicts with the configuration files in /etc.

Now I did pull to latest git and did not compile with adviced prefix flag and my problem is gone

Latest update fixes my problem.

In my older Firejail version I tested moving files to etc firejail and even than I had same error.

Now reverted etc firejail and latest update solve my problem.

[osevan]

I have same issue again with newest Firejail.

I dunno why )-:

[osevan]

Sounds like user nginx doesn't have read-access rights to these .local files. Do you have those in /etc/firejail or under your regular user's ${HOME} in ~/.config/firejail? Somewhere else?

Also, it would be helpful to know/see if your systemd unit uses security options like ProtectHome, ProtectSystem etcetera. The differences might account for what you're seeing, doesn't necessarily need to be a Firejail bug.

I haven't any locale files in these directorys.

Snd for security im creating users without home directory

I have my problem back :-(

[osevan]

i have tested this bug now on 3 vps, sometimes nothing happens 6 months, but than , when firejail process running too long or restarted things often enough well and successfully, trouble above comes back...

i dont know how to fix it, because, --noprofile works well, but, when i create nginx.profile with only one line trash line like #log nothing starts and i see emerge fcopy files error again... :-(

i know its bad, when i running firejail --debug mode and no usefull information i can post here :-(

even right read access i did try chown -R nginx:nginx /etc/nginx/ and with chown -R root:root /etc/nginx.

but dont forget my nginx profile running well 5-6 months with root:root /etc/nginx and nothing happens.. i dont know what triggers that kind of problem :-(

[osevan]

This is strangest firejail bug i got in last 5 years :-(

[osevan]

bug dissappears again suddenly without doing anything :-)

[osevan]

Hello devs.

We are now in 2024 and on vps debian sid my trouble still exist.

Im installed over make deb everything inside /usr.

And when my profile have shell none, i cant start daemons with systemd

Only when i remove "shell none "

sudo -u mysql -H firejail mydaemon i receive:

Error : cannot access profile file : server.local

And exit

[glitsj16]

And when my profile have shell none, i cant start daemons with systemd ... sudo -u mysql -H firejail mydaemon Error : cannot access profile file : server.local

The mysql user more than likely doesn't have access rights to ~/.config/firejail/server.local (if that is where you've put it). In general I'd use systemd's sandboxing features instead of firejail (which is by design not very well suited for system daemons). See this wiki page.

That being said, try placing your override in /etc/firejail/server.local and add the allusers option.

[osevan]

Where i can find allusers option? Ok thx