openwrt / luci

LuCI - OpenWrt Configuration Interface
Apache License 2.0
6.28k stars 2.51k forks source link

Permission problem with luci-base.json when build-system uses "umask 0022" #1521

Closed torte71 closed 6 years ago

torte71 commented 6 years ago

Targets: System independent (seen on raspberry pi3, gl-ar150 and wr842) Version: git-head (probably in earlier versions as well) Module: luci-base

See also here: https://github.com/freifunk-berlin/firmware/issues/431

When building luci-base on a system with a default umask 0022, luci will not be usable for non-root users in the resulting image (non-root access is enabled e.g. in the freifunk package). For non-root users, it will just display a "500 internal server error", because ubusd requires the file "/usr/share/acl.d/luci-base.json"[1] to be not group-readable[2]. As a result, access to ubus/system/board will not be allowed, leading to a NIL value for the boardinfo object in "/usr/lib/lua/luci/view/themes/bootstrap/header.htm"[3], what causes a crash, when trying to access its "hostname"[4] property.

The reason is, that the "install" section in "luci.mk"[5] does not set the required permission - it just copies the directories, retaining the permissions, that the files have from "git clone". If you are lucky to be compiling on a host with a "umask 0002" setting, the luci-base.json will have rw-r--r-- permission and everything works fine. On a system with "umask 0022" (this is nothing unusual), it will have rw-rw-r-- permissions after the checkout, resulting in a non-usable luci in the final image.

As a workaround, one can issue "umask 0002" before "git clone"ing. To really solve it, luci.mk may use "chmod" or "$(INSTALL_DATA)" on this file to ensure, the file gets installed with the correct permissions.

How to reproduce:

(Please note, that the Freifunk-module is only used to easily demonstrate the consequences of this issue. The output from restarting ubusd shows, that the permission problem already exists in a vanilla luci-base installation).

[1] affected file "/usr/share/acl.d/luci-base.json" https://github.com/openwrt/luci/tree/master/modules/luci-base/root/usr/share/acl.d

[2] permission check in ubusd https://git.lede-project.org/?p=project/ubus.git;a=blob;f=ubusd_acl.c;h=4b72663d25aa983cb65b10fae8ba029b099c7c45;hb=HEAD#l406

[3] NIL value for boardinfo = util.ubus("system", "board") https://github.com/openwrt/luci/blob/master/themes/luci-theme-bootstrap/luasrc/view/themes/bootstrap/header.htm#L14

[4] crash accessing boardinfo.hostname https://github.com/openwrt/luci/blob/master/themes/luci-theme-bootstrap/luasrc/view/themes/bootstrap/header.htm#L162

[5] "install" section from luci.mk https://github.com/openwrt/luci/blob/master/luci.mk#L169

jow- commented 6 years ago

I am unable to verify this problem here. Compiled this test program:

#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
    struct stat st;

    if (stat("/usr/share/acl.d/luci-base.json", &st)) {
        printf("stat failed\n");
        return 1;
    }

    if (st.st_uid || st.st_gid) {
        printf("wrong owner\n");
        return 1;
    }

    if (st.st_mode & (S_IWOTH | S_IWGRP | S_IXOTH)) {
        printf("has wrong permissions\n");
        return 1;
    }

    printf("permissions okay\n");
    return 0;
}

Ran it on a target device:

root@jj:~# ls -lh /usr/share/acl.d/luci-base.json
-rw-r--r--    1 root     root          91 Jul  2  2017 /usr/share/acl.d/luci-base.json
root@jj:~# /tmp/test 
permissions okay
root@jj:~# 
jow- commented 6 years ago

You probably swapped your with/without error cases. Builds with umask != 022 are known to be broken, OpenWrt added a prereq check due to this, see https://github.com/openwrt/openwrt/blob/master/include/prereq-build.mk#L25

The problem you raise here is not specific to LuCI and will affect a lot of other packages as well so I am not sure if it makes sense to add workarounds or checks to address this specific arbitrary case.

torte71 commented 6 years ago

Oops, indeed I swapped those values. But looking at the grep from the prereq test: This would return true for 0022 and 0002 (and some more). That explains, why I never encountered that message.

jow- commented 6 years ago

This needs to be solved in OpenWrt buildroot and/or the host system.