LuCI inaccessible in current master-builds

[Akira25]

Bug report

What is the problem? Flashing a GL-AR150 with a current master-build (673a177 – master (29) from 2020-04-18 00:39:24) results in a somewhat bricked LuCI. Connecting to http://frei.funk fails. instead it states:

Forbidden
You don't have permission to access /cgi-bin/luci on this server.

Hence, the wizard cannot be reached.

What is the expected behaviour? Calling for http://fei.funk should give the set-password-page of the wizard

Firmware Version: Development. 673a177 – master (29) from 2020-04-18 00:39:24

Site Configuration: I tested the notunnel-Image. Presumable all images are concerned

[SvenRoederer]

I've seen this also on a GLinet MT300n (Firmware Freifunk Berlin (Dev-daily-1907 rev 3d078ce); Generic - ramips/mt7620) It's from the buildbot http://buildbot.berlin.freifunk.net/#/builders/5/builds/33

This message is generated by uhttpd (https://git.openwrt.org/?p=project/uhttpd.git;a=blob;f=cgi.c;h=13a0bc480b633cbfdd2f10565595a2a33dd2367c;hb=HEAD#l67), which seems to check for a regular file with execution-bit set for others. On the router the permission for /www/cgi-bin/luci are 0700, when changing to 0701 the output changes to something from the lua-interpreter. But lua is also complaining about bad permissions.

[SvenRoederer]

Just did the following test (also using master 673a177; mt7620):

• build: http://buildbot.berlin.freifunk.net/#/builders/5/builds/37; worker foobar --> WebUI is fine

  root@gib-mir-einen-namen:~# ls -l /rom/www/cgi-bin/luci 
  -rwxr-xr-x    1 root     root           135 Feb 27 21:05 /rom/www/cgi-bin/luci

• build: http://buildbot.berlin.freifunk.net/#/builders/5/builds/38; worker wg1337 --> WebUI gives error

  root@gib-mir-einen-namen:~# ls -l /rom/www/cgi-bin/luci 
  -rwx------    1 root     root           135 Feb 27 21:05 /rom/www/cgi-bin/luci

@Akira25 your firmware is from build 29 (http://buildbot.berlin.freifunk.net/#/builders/2/builds/29), right?
So it was build on worker wg1337 for ar71xx-generic.

It seems that 673a1773fb9f3bd5342225ad545f31a8e36a0ca1 fixes the build-predependencies of OpenWrt, but still don't fix the permission problem. But so it seems that there is still something wrong in OpenWrt regarding the test and the code creating the image.

[SvenRoederer]

As the mentioned commit was cherry-picked to Hedy-1.0.6 branch (16cb778a64fb71180e407bd79f1bf11b58e29da7) this series might also be affected.

[SvenRoederer]

I triggered build 41 and 42 for ramips-mt7620 which built 16cb778 on both workers and both images seem fine. So no issue for Hedy-1.0.6.

[everloop2]

my local build: LuCI branch (git-19.249.30590-ddf030e) / Freifunk Berlin Development 673a177 (master)

LuCI working ;)

[SvenRoederer]

@everloop2 What is your umask set to? Can you rebuild after "git revert 673a1773fb" and report if it fails?

[SvenRoederer]

To me it looks like 673a1773fb9f3bd5342225ad545f31a8e36a0ca1 of PR #785 fixes the error-message generated when running the image-builder, but the problem that was addressed in OpenWrt by this check, still persists.

[everloop2]

@everloop2 What is your umask set to? Can you rebuild after "git revert 673a177" and report if it fails?

i set umask to 0022 if building.

did "git pull" at master:

set umask 0022 -> freifunk-berlin-development-673a177 -> builds and LuCI working

then closed/opened terminal - umask by default set to 0002

umask 0002 -> freifunk-berlin-development-673a177 -> builds and LuCI working

then "git revert 673a177":

umask 0002 -> freifunk-berlin-development-233ba34 -> builds and LuCI working

then set "umask 0022"

umask 0022 -> freifunk-berlin-development-233ba34 -> builds and LuCI working

[SvenRoederer]

I made some test with images build by the buildbot using x86-generic target, where a rootfs.tar.gz is created.

• running the imagebuilder locally resulted in the same working / faulty images based on the build-worker the imagebuilder was made on. The local umask had no effect.
• checking the compiled packages shows the following when running wget -q -O - $PACKAGE | tar xz ./data.tar.gz --to-stdout | tar -tzv ./www/cgi-bin/luci
  • build 64 (branch daily/upstream-19.07, revision 4d2a783, builder: "foobar"):
  • http://buildbot.berlin.freifunk.net/#/builders/1/builds/64
  • PACKAGE="http://firmware.berlin.freifunk.net/unstable/x86-generic/64/packages/packages/i386_pentium4/luci/luci-base_git-19.249.30590-2bb4c0e-1_i386_pentium4.ipk"
  • result: -rwxr-xr-x root/root 135 2019-09-06 10:29 ./www/cgi-bin/luci
  • build 66 (branch daily/upstream-19.07, revision b1e2b4b, builder: "wg1337"):
  • http://buildbot.berlin.freifunk.net/#/builders/1/builds/66
  • PACKAGE="http://firmware.berlin.freifunk.net/unstable/x86-generic/66/packages/packages/i386_pentium4/luci/luci-base_git-19.249.30590-cd41ca6-1_i386_pentium4.ipk"
  • result: -rwx------ root/root 135 2019-09-06 10:29 ./www/cgi-bin/luci

This shows that the bad permissions are already set when building the package. Later the imagebuilder just uses the stored package-permissions in the final image also. So we need to check for the correct permissions when building the packages already.

[SvenRoederer]

@everloop2

i set umask to 0022 if building.

did "git pull" at master:

set umask 0022 -> freifunk-berlin-development-673a177 -> builds and LuCI working

did you also removed the luci-feed from the openwrt folder? I assume the umask gets only applied then creating the file from scratch by doing a git checkout (which is called by scripts/feeds install of openwrt). Without creating the files from scratch the existing permissions will likely preserved, which seem in your case to be correct.

[everloop2]

@everloop2

i set umask to 0022 if building. did "git pull" at master: set umask 0022 -> freifunk-berlin-development-673a177 -> builds and LuCI working

did you also removed the luci-feed from the openwrt folder? I assume the umask gets only applied then creating the file from scratch by doing a git checkout (which is called by scripts/feeds install of openwrt). Without creating the files from scratch the existing permissions will likely preserved, which seem in your case to be correct.

master i build -> https://github.com/freifunk-berlin/firmware:

did not remove LuCI only "git pull" and afterwards "git revert".

Remember in past there was a LuCI issue about setting "umask 0022" for a fresh "git clone https://github.com/freifunk-berlin/firmware.git" - without "umask 0022" permissions of clone did not match source and LuCI was broken.

seen this building freetz -> https://github.com/Freetz/freetz/blob/master/Makefile

# Folder root/ needs 755 permissions
ifneq ($(shell stat -c %a make/mod/files/root),755)
$(error Wrong build directory permissions. Please set umask to 0022 and then
unpack/checkout again in a directory having no uid-/gid-bits set)
endif

My first step for cloning / building: "umask 0022"

/firmware$ umask 0022
/firmware$ make -j4 V=s TARGET=lantiq-xway PACKAGES_LIST_DEFAULT=notunnel
rm -f ../firmware_master/firmware/openwrt/.config
rm -f .stamp-
cat ../firmware_master/firmware/configs/common.config ../firmware_master/firmware/configs/lantiq-xway.config >../firmware_master/firmware/openwrt/.config
# always replace CONFIG_VERSION_CODE by FW_REVISION
sed -i "/^CONFIG_VERSION_CODE=/c\CONFIG_VERSION_CODE=\"233ba34\"" ../firmware_master/firmware/openwrt/.config
umask 022; \

-> umask is set to 0022 automagically if building

[everloop2]

machine i am building on: switched from ubuntu (debian) to manjaro (arch) linux

seems ubuntu (debian) umask defaults to 0002 -> open terminal -> umask

manjaro (arch) defaults to 0022

[SvenRoederer]

should be fixed by 5766e97; let's wait for the build to finish.

[SvenRoederer]

it was build in http://buildbot.berlin.freifunk.net/#/builders/2/builds/92 on host wg1337. LuCI starts correctly, but shows an lua-error related to the updates of the "daily/upstream-1907" branch.

[SvenRoederer]

backported 5766e97 to ef31a4c83e4c27003ab5a9a6af180ba9a74a473f on master; should be fixed.