mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #6798] private-etc: Error: invalid file type, /etc/login.defs. (file mode 640, OpenMandriva) #3377
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3377
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ZeroAbility on GitHub (Jul 5, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6798
Description
nheko does not open when using a profile.
Steps to Reproduce
Steps to reproduce the behavior
LC_ALL=C firejail /path/to/program(LC_ALL=Cto get a consistentoutput in English that can be understood by everybody)
ERRORExpected behavior
nheko opens successfully.
Actual behavior
nheko does not open
Behavior without a profile
nheko opens:
Additional context
strace:strace
Environment
uname -srm): Linux 6.15.4-desktop-2omv2590 x86_64mesa 1:24.3.3-2"): nheko.x86_64 0.12.0-4 cooker-x86_64
firejail --version): 0.9.74was compiled (
git rev-parse HEAD): n/aChecklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
Output of
LC_ALL=C firejail /path/to/programOutput of
LC_ALL=C firejail --debug /path/to/program@kmk3 commented on GitHub (Jul 5, 2025):
What happens when using /etc/firejail/nheko.profile?
What is the output of the following?
@ZeroAbility commented on GitHub (Jul 5, 2025):
I believe this negates it (from
--debug):Disable /home/<user>/.config/firejailBut it does the same thing. It's a copy of the
/etc/profile plus this change:private-etc @tls-ca,@network,@sound,@x11,host.conf,mime.types,os-releaseFor consistency's sake:
LC_ALL=C firejail --profile=/etc/firejail/nheko.profile --debug /usr/bin/nheko@ZeroAbility commented on GitHub (Jul 5, 2025):
The
login.defserror comes up on a lot of things (likessh) that work. nheko worked in the previous version. I simply updated the version number in our package spec and now it does not.@ZeroAbility commented on GitHub (Jul 5, 2025):
More diagnosis:
This will run, but trying to run after closing it will produce the same error:
firejail --build=~/.config/firejail/nheko.profile /usr/bin/nhekoThe only thing that absolutely will work in any profile is to comment out
private-etc.@kmk3 commented on GitHub (Jul 5, 2025):
I'd suggest placing the generated profile somewhere else to avoid accidentally
using it; see:
The message seems to be from this code:
https://github.com/netblue30/firejail/blob/9bc9b8af4e727adbcb3e923e5e8f4faa7f8443cc/src/firejail/fs_etc.c#L245-L267
It doesn't look like it should fail given your /etc/login.defs output.
Also, it seems like "invalid file type" is also printed for when the file
cannot be accessed, so the error messages could be improved.
Since it's owned by
root:shadowinstead of the usualroot:root, the issuemight be related to groups.
Does it work with the following in ~/.config/firejail/nheko.local?
If not, you can try commenting nheko.profile until you find which lines are
causing problems and then post them in here.
So does commenting it entirely fix the problem?
You can try using
--trace=trace.txtto see what else it accesses in /etc.Example:
Likely relates to:
@ZeroAbility commented on GitHub (Jul 5, 2025):
I created a directory specifically to isolate from that location just now and used the same path for the
--profile=option and it gets the same error.No.
Yes.
I get a blank file. I included the
straceof the standard binary in the "Additional context" section above.@kmk3 commented on GitHub (Jul 5, 2025):
Does that
private-etcline entirely fix the problem?If not, what does it change?
Strange, what is the output when
--debugis also used?Examples:
libtrace is known to not compile using musl:
What is the name/version of the C compiler and libc used to compile firejail?
I see, thanks.
It might be useful to also try
--trace=%fileto ensure that all callsinvolving filenames are included.
Example:
@ZeroAbility commented on GitHub (Jul 5, 2025):
No, it was purely a diagnosis step based on the include file. It isn't clear in the file if those are part of the
private-etcor not.The file is also blank. Not sure if it's related to this:
@ZeroAbility commented on GitHub (Jul 5, 2025):
@kmk3 commented on GitHub (Jul 5, 2025):
But what is in the normal program output (stdout/stderr)?
What happens if you enable it in the config and re-run?
Is there anything in the syslog?
Just to make sure, is
libc6glibc?The libtrace code is rather brittle, so it might also be broken on clang.
I see some other files that are not in
private-etc.So the following should be more complete (files in
xdgshould already beincluded by
@x11):Back to the original problem:
Are
UID_MINandGID_MINset in /etc/login.defs?Does it work if you temporarily do the following?
To restore it later:
@kmk3 commented on GitHub (Jul 5, 2025):
This might be unrelated:
Are you sure that
./configureis still executed with this change?It's very important that
./configureis called so that config.mk is generatedwith the proper values.
Otherwise a lot of things will likely be missing.
What is the output of
firejail --version?@ZeroAbility commented on GitHub (Jul 5, 2025):
trace_true.txtcontents:trace_nheko.txtcontents:nullIt appears trace is working, but not for nheko.
Yes.
I tried to modify it in some way that included this and the others I saw in the original
straceand it didn't make a difference.autoreconf -fishould fire off./configureand is seen in the build log here:https://file-store.openmandriva.org/api/v1/file_stores/80e0d8c79ea295f90857519a6f1a0fb64da4f6e0.log?show=true
Calling
./configureagain can lead to unintended side effects."Version of Firejail (firejail --version): 0.9.74"
I would think this issue would extend to other sandboxed applications but it doesn't. I'm using Brave among other applications without issue. Now that I say that, Steam is also broken. I will try another build of firejail with just
configureand see if there are any changes.@ZeroAbility commented on GitHub (Jul 5, 2025):
./configurewas already revised 2 days ago:41eaf9d566@ZeroAbility commented on GitHub (Jul 5, 2025):
Yes they are.
Yes it does.
@ZeroAbility commented on GitHub (Jul 5, 2025):
It seems this is sufficient enough to allow nheko to start.
@kmk3 commented on GitHub (Jul 5, 2025):
By default it should only generate (but not run)
./configure(and relatedfiles), unless
-mis used:From
autoreconf(1):I agree that ideally it would only be executed once, but in general, all
./configuredoes is generate the files inAC_CONFIG_FILES(which isconfig.mk/config.sh in this project) and also print a few things.
What would be an example of an unintended side effect?
I see, good catch.
I think it would be a good idea to keep both:
The autoconf version of the distribution might be more up-to-date and it would
help prevent things like the xz backdoor (see #6316).
Can you provide the full output to see which features are enabled by default on
OpenMandriva?
So I suppose that the issue is:
private-etccurrently has a hard dependencyon /etc/login.defs, which is not world-readable (and thus not readable by
firejail) on OpenMandriva.
This is likely because the private-etc refactor (#6400) added login.defs to the
default group for
private-etc.If so, as a workaround you can either keep /etc/login.defs with file mode 644
or add the following to /etc/firejail/globals.local (or
~/.config/firejail/globals.local):
What is the output of the following?
@ZeroAbility commented on GitHub (Jul 5, 2025):
We weren't affected by that, but we mitigated it anyway.
Here is the full version output:
I am certain that is a security mitigation. Rocky has owners and permissions set as you had me set them.
@ZeroAbility commented on GitHub (Jul 5, 2025):
Ideally, we will want to get to a point where we can use declarative builds. I will address that in another issue, if needed. We will discuss internally if adding the
autoreconf -fiback into the spec is a good path forward since it doesn't seem to need it.@ZeroAbility commented on GitHub (Jul 10, 2025):
To come back to this:
I think we would like to keep the permissions as they are, since it could expose things that should not be readable outside the system. Several profiles are referencing the file as part of
private-etcwhich would mean several.localoverrides or a potential fix upstream.@kmk3 what are your thoughts?
@ZeroAbility commented on GitHub (Jul 16, 2025):
This did not work, unfortunately. I did add it to
nheko.localand that seems to have worked.@kmk3 commented on GitHub (Jul 19, 2025):
Strange that it worked.
In that case, I'm not sure what combination is required to cause the issue.
Could you try commenting nheko.profile until you get only the lines that are
needed to reproduce this?
It should work at least for /etc/firejail/globals.local when using the upstream
nheko.profile.
If you're using a custom profile, make sure to include globals.local in it as
well.
What do you mean by "outside the system"?
Outside of system accounts?
Maybe access failure for
private-etccould be turned from an error into awarning.
In the mean time, since access to that file is currently needed for
private-etc, how about adding the user(s) that run firejail into the shadowgroup since that is the group that owns login.defs?
Misc: Some profiles mention login.defs and #2877, so it might be related:
@ZeroAbility commented on GitHub (Jul 19, 2025):
The
otherpermission is all users on the system. They wouldn't really have a need to read/etc/login.defs. From my understanding,otheris only slightly more secure than the filesystem permission type "Everyone" on Windows.This isn't really recommended, either. There shouldn't be any users with membership in that group. If I'm following the logic, it's to pass down read only defs to the users, but those that would not have to log in (i.e. a guest account) would still be able to read the contents of files with the
o=rxxpermission set. That should be handled elsewhere and there may be things in the file you don't even want authenticated users to read. It could also be a simple misunderstanding on my part, so forgive me if it is.I will try this again. Is there a way to just exclude
/etc/login.defsfromprivate-etc?@kmk3 commented on GitHub (Jul 20, 2025):
I'm not sure why you mention
otherando=rxx, but there is no need tochange the file permissions, only to add the relevant user to the
shadowgroup.
That is, only root and users in the
shadowgroup (presumably only ashadowsystem user and the user running firejail) would be able to read the file.
IIRC firejail can use information in that file to keep only system users/groups
and supplementary groups in the sandbox while excluding normal users/groups.
It's unfortunate that something as basic as variables for
UID_MIN/UID_MAX, etc are stored in the same file as configuration for login attemptsand type of encryption.
Though those details do not seem all that sensitive to me, at least on a
desktop system and for a user that is allowed to run firejail.
See also:
Currently no.
But feel free to open a feature request.
@ZeroAbility commented on GitHub (Jul 20, 2025):
Perhaps a
firejailgroup would be a good idea. I have no clue if that was mentioned or not. I will try to read the PR you linked when my schedule opens up.I will consider this, as well.
@kmk3 commented on GitHub (Jul 22, 2025):
Creating a
firejailgroup is possible and is documented infirejail-users(5):Though that is intended just for the SUID executable.
I'd imagine that changing group ownership on system files could lead to issues
if for example there are package management hooks or system maintenance
cronjobs that by default operate under system users/groups rather than root
(see also esysusers).
That is, it could probably work but it would likely not be my first suggestion
to users.
@davidebeatrici commented on GitHub (Mar 7, 2026):
I propose to add a configuration setting that allows to set
uid_minandgid_minexplicitly.