OK, any suggestions?
Yours seems to be a more severe case Could you check if any directories like /usr, /usr/bin, /usr/sbin, /usr/lib and /var have permissions different than 755?
I am clearly biased, because I am running a shop with a wonderful selection of appliances designed and tested by the IPFire developers that suit everyone at:
I just noticed that your device has the oldest Intel Atom processor that can run 64 bit code. If you bought that system a while ago that is fine, but if you bought it recently someone sold you some old stuff for the price of a new system.
A firewall does not need to run on the latest generation, but in general I would feel happier if people gave my software a good home to live in.
yeahhh - that´s it!
You solve my Problem right now.
These are fine as they are
OK, did it and also chmod 755 other folders… Still no GUI, what else can I do?
P.S. I guess the system hangs on reboot -
Prepare for reboot...
If your system is booting successfully, please run at the root directory ‘/’ the command
find -type d -perm 700
and post the output here.
./lost+found ./var/db/sudo/lectured ./var/cache/ldconfig ./var/ipfire/ovpn/certs ./var/lib/sasl ./boot/lost+found ./root/.ssh ./opt/pakfire/etc/.gnupg
That looks fine.
OK, GUI is up now… thank you! I had problems with openvpn, is this:
You do not want any certificates to be world-readable, so changing permissions of all directories to 755 is a very bad idea. Only OpenVPN needs to read their own certificates.
I can test openvpn tomorrow. I will tell you the result if you like… Again, thank you very much!
I just make the update to 158, it was strange it give this error;
After going to the Ipfire main webpage it was ok, after rebooting it’s look to work fine.
When i check in the wui i logs i dont see any error.
I just thought to let you know what I experienced
I think, I Find the error I was searching for:
[Wed Jul 21 19:36:07.017812 2021] [cgid:error] [pid 1209:tid 125533514019840] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cgi' failed [Wed Jul 21 19:36:07.018374 2021] [cgid:error] [pid 17096:tid 125533228623424] [client 192.168.10.200:47120] End of script output before headers: speed.cgi, referer: https://192.168.10.110:444/ [Wed Jul 21 19:36:09.014290 2021] [cgid:error] [pid 1210:tid 125533514019840] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/pakfire.cgi' failed [Wed Jul 21 19:36:09.014787 2021] [cgid:error] [pid 17096:tid 125533466687040] [client 192.168.10.200:47126] End of script output before headers: pakfire.cgi [Wed Jul 21 19:36:09.025292 2021] [cgid:error] [pid 1211:tid 125533514019840] (13)Permission denied: AH01241: exec of '/srv/web/ipfire/cgi-bin/speed.cgi' failed [Wed Jul 21 19:36:09.025795 2021] [cgid:error] [pid 17096:tid 125533449901632] [client 192.168.10.200:47130] End of script output before headers: speed.cgi, referer: https://192.168.10.110:444/ [Wed Jul 21 19:36:33.777329 2021] [cgid:error] [pid 17092:tid 125533514019840] AH01239: cgid daemon process died, restarting [Wed Jul 21 19:36:34.782071 2021] [mpm_event:notice] [pid 17092:tid 125533514019840] AH00491: caught SIGTERM, shutting down [Wed Jul 21 19:36:35.818474 2021] [ssl:warn] [pid 1604:tid 123996857816064] AH01909: PegasusFirewall.Neoaurora.net:444:0 server certificate does NOT include an ID which matches the server name [Wed Jul 21 19:36:35.828754 2021] [ssl:warn] [pid 1605:tid 123996857816064] AH01909: PegasusFirewall.Neoaurora.net:444:0 server certificate does NOT include an ID which matches the server name [Wed Jul 21 19:36:35.831087 2021] [mpm_event:notice] [pid 1605:tid 123996857816064] AH00489: Apache/2.4.48 (Unix) OpenSSL/1.1.1k configured -- resuming normal operations [Wed Jul 21 19:36:35.831175 2021] [core:notice] [pid 1605:tid 123996857816064] AH00094: Command line: '/usr/sbin/httpd' [Wed Jul 21 19:38:21.358274 2021] [mpm_event:notice] [pid 1605:tid 123996857816064] AH00491: caught SIGTERM, shutting down [Wed Jul 21 19:40:50.725988 2021] [ssl:warn] [pid 16985:tid 127807966901248] AH01909: PegasusFirewall.Neoaurora.net:444:0 server certificate does NOT include an ID which matches the server name [Wed Jul 21 19:40:50.740429 2021] [ssl:warn] [pid 16992:tid 127807966901248] AH01909: PegasusFirewall.Neoaurora.net:444:0 server certificate does NOT include an ID which matches the server name [Wed Jul 21 19:40:50.743534 2021] [mpm_event:notice] [pid 16992:tid 127807966901248] AH00489: Apache/2.4.48 (Unix) OpenSSL/1.1.1k configured -- resuming normal operations [Wed Jul 21 19:40:50.743672 2021] [core:notice] [pid 16992:tid 127807966901248] AH00094: Command line: '/usr/sbin/httpd'
I need to say everything is working fine but as I noticed that there are more people with problem maybe this can help.
This is the output on my machine:
[root@ipfire /]# find -type d -perm 700
find: ‘./proc/27439/task/27439/net’: Invalid argument
find: ‘./proc/27439/net’: Invalid argument
./usr ← this one
./usr/share ← this one
./usr/share/nmap ← this one
[root@ipfire /] #
I marked the last three ones that should be probably corrected to 0755. Are my assumptions correct? Did I miss anything else?
since there are actually two issues discussed in this thread, I will try and bring some light into it:
It is fine to experience an “Internal Server Error” or a temporarily unresponsive web interface during the update. This is because we change all the CGIs in the background due to this security vulnerability. Since there is a short timeframe where some CGIs are updated and some are not, quirks are expected here.
This behaviour should only last for a couple of seconds, and everything should behave fine afterwards again without any manual interaction.
Any other issues we are currently aware of are caused by a
tarbug, which is apparently causing directory permissions to go down the drain on some systems (we do not really know how this group of affected IPFire installations look like).
This is fixed by this commit, and cannot happen again in future releases. However, there is a chicken-and-egg problem here, as existing installations will extract the update using the old
tarcommand - this is why, despite being fixed, this error appears in production.
However, to prevent any further damage, this commit has been added after the release of Core Update 158, and fixes potentially bogus permissions for good measure.
All installations not yet upgraded to C158 should therefore not run into these errors.
To repair semi-broken installations, all you need to do is to run the command introduced in the second commit:
chmod -v 755 /usr /usr/bin /usr/lib /usr/sbin /var /var/ipfire
As @ms already pointed out, please do not set other permissions, or be too permissive: Insecure file system permission are a huge security threat, especially when it comes to confidential files such as private keys.
Needless to say, users are as always strongly advised to keep their IPFire machines up to date.
Also, please test Core Updates and provide feedback on them. The more people are doing so, the better - especially if they are running setups we are not aware of or are unable to test ourselves.
To avoid duplicates and confusion, please use this thread for questions related to (2) only. Should you experience any different issues, please open up new threads for them, so we investigate step by step.
I will close duplicate threads discussing the same problem, and link them to this one. Feel free to continue conversations related to (2) here.
Thanks, and best regards,
Please note that I also experienced wrong permissions of
See one of my above messages. This prevented openvpn and avahi to work.
I have corrected permissions of /usr , and both OpenVPN client access as well as WebGUI are working again
I have also corrected permissions of /usr/share and /usr/share/nmap to 0755, because these are set to 0755 on another working machine. If this is incorrect, please advise.
Used Pakfire to Update two similar PCs from core 157 to core 158.
After the update, I could NOT connect via the WUI to either PC ?
Nuked both PCs and did a new install of core 158 on one PC and a new install of core 156 on the other.
After the install, I could connect via the WUI to both PCs.
Used Pakfire to Update the PC /w core 156 to core 158.
After the update, I could connect via the WUI to both PCs.
Why the core 157 to 158 update caused the WUI problem is a mystery to me.
the same Trouble when upgrading from core 158 to core 159…
Here solved the Problem from ms
I hope the next upgrade is possible without Problems
Have a nice Day!
EDIT: mod corrected the quote from ms.