Ubus call for network.device returning access denied

For Developers
1

Hi all

I'm having some issues with the newly minted Homepage widget for OpenWRT.

The widget makes a call to network.device via ubus to get some information to display, however without fail (even when using the root user via a CURL command), the response is Access Denied.

CURL (note I have also tried specifying the interface as well but based on outuput from ubus in the cli it should just give all of the interfaces if that's not specified?):

curl -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["0b33ddba75282a7a4ceb23d932ebef48", "network.device", "status", {}] }'  http://192.168.1.1/ubus | jq

Output:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32002,
    "message": "Access denied"
  }
}

And with the same login session, other calls work fine:

curl -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["0b33ddba75282a7a4ceb23d932ebef48", "system", "info", {}] }'  http://192.168.1.1/ubus | jq

Output:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [
    0,
    {
      "localtime": 1709074097,
      "uptime": 1145305,
      "load": [
        2784,
        1984,
        32
      ],
      "memory": {
        "total": 8122626048,
        "free": 7088615424,
        "shared": 470683648,
        "buffered": 3534848,
        "available": 7162826752,
        "cached": 631521280
      },
      "root": {
        "total": 241066028,
        "free": 240846496,
        "used": 219532,
        "avail": 240830112
      },
      "tmp": {
        "total": 3966124,
        "free": 3506640,
        "used": 459484,
        "avail": 3506640
      },
      "swap": {
        "total": 0,
        "free": 0
      }
    }
  ]
}

I can't find anywhere in the documentation which says that network.device access is restricted by more than just the basic ACL, or needs to be opened up - but does anyone have any information about that they can share?

The thread for this issue with the widget itself is here: https://github.com/gethomepage/homepage/discussions/3012#discussioncomment-8606568

2

What is the brand and model of the device you are using?

3

Sorry - x86/64. Noname N5105 with 4x i226v NICs.

Running on bare metal.

4

And where did the OpenWrt version you installed come from?

5

Firmware Selector, specifically with these settings:
https://firmware-selector.openwrt.org/?version=23.05.2&target=x86%2F64&id=generic

6

Ok... good. We have seen some situations where the entire ubus call command returns an access denied or not found -- those typically happen for vendor forks that are more 'locked down' than most.

What is the exact call you are making?

7

Makes sense!

The call is simply "network.device", "status", {} via http.

The "system", "info", {} call returns an expected response.

SSH'd to the cli ubus call network.device status returns the expected results.

8

How do you setup the session? Do you reuse LuCI infrastructure?

There's multiple issues in the configuration files posted in the referenced Github issue:

config login
        option username 'homepage'
        option password '$p$homepage'
        list read homepage
        list write '*'
  • The list write '*' will grant write access for all ACL groups present on the system, since the intent is to create a restricted, readonly "homepage" login you should remove the list write '*' line
{
        "homepage": {
                "description": "Homepage widget",
                "read": {
                        "ubus": {
                                "network.interface.wan": ["status"],
                                "network.interface.lan": ["status"],
                                "network.device": ["status"]
                                "system": ["info"]
                        }
                },
        }
}
  • Missing comma after "network.device": ["status"]
  • Extraneous comma in the third closing brace from the end

The few working calls might have been due to the fact that other, unrelated ACLs got applied to the session.

You can see the effective session ACLs with ubus call session list on the cli. When properly set up, it should look like this:

root@fb7530:~# ubus call session list
[...]
{
	"ubus_rpc_session": "3540f29ecdca735438e9fe188e99768a",
	"timeout": 300,
	"expires": 234,
	"acls": {
		"access-group": {
			"homepage": [
				"read"
			]
		},
		"ubus": {
			"network.device": [
				"status"
			],
			"network.interface.lan": [
				"status"
			],
			"network.interface.wan": [
				"status"
			],
			"system": [
				"info"
			]
		}
	},
	"data": {
		"username": "homepage"
	}
}
root@fb7530:~#

Setup used for testing:

root@fb7530:~# cat /etc/config/rpcd 
config rpcd
	option socket /var/run/ubus/ubus.sock
	option timeout 30

config login
	option username 'root'
	option password '$p$root'
	list read '*'
	list write '*'

config login
        option username 'homepage'
        option password '$1$$ysVNzQc4CTMkp5daOdZ.3/'
        list read homepage

root@fb7530:~# cat /usr/share/rpcd/acl.d/homepage.json 
{
        "homepage": {
                "description": "Homepage widget",
                "read": {
                        "ubus": {
                                "network.interface.wan": ["status"],
                                "network.interface.lan": ["status"],
                                "network.device": ["status"],
                                "system": ["info"]
                        }
                }
        }
}
root@fb7530:~#

Test calls:

jow@j7:~$ curl -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["00000000000000000000000000000000", "session", "login", { "username": "homepage", "password": "secret" }] }' http://fb7530/ubus
{"jsonrpc":"2.0","id":1,"result":[0,{"ubus_rpc_session":"6a7c64e93546f08457b86783bae6505d","timeout":300,"expires":299,"acls":{"access-group":{"homepage":["read"]},"ubus":{"network.device":["status"],"network.interface.lan":["status"],"network.interface.wan":["status"],"system":["info"]}},"data":{"username":"homepage"}}]}
jow@j7:~$ curl -H 'Content-Type: application/json' -d '{ "jsonrpc": "2.0", "id": 1, "method": "call", "params": ["6a7c64e93546f08457b86783bae6505d", "network.device", "status", {}] }'  http://fb7530/ubus 
{"jsonrpc":"2.0","id":1,"result":[0,{"br-lan":{"external":false,"present":true,"type":"bridge","up":true,"carrier":true,"auth_status":false,"link-advertising":[],"link-partner-advertising":[],"link-supported":[...
2 Likes
9

Thank you!

Yes - the config there is based on the docs for the widget, I wanted to follow it as closely as possible to help the creator diagnose the issue. I'll make some adjustments to my config and see if it works - though looking at your results I am pretty confident.

Thanks again - will come back to confirm and provide a PR for the widget.

Editing to say that is the fix. I will submit a PR to update the docs for the widget.

1 Like
10

If you're going to revise the docs anyway, I would also suggest to setup the homepage rpcd login with a local password (an actual crypt(5) hash instead of a $p$... one referencing an /etc/shadow entry). This way you do not need to setup a real system user (which would also grant SSH access unless further measures are taken).

One way to create such a crypt hash on OpenWrt itself is using the uhttpd -m command:

root@fb7530:~# uhttpd -m "super secret"
$1$$skHE1XxizjyjhAy03YPwr.

Another is using the mkpasswd command on a Desktop system:

jow@j7:~$ mkpasswd -m md5crypt "super secret"
$1$C3XJjAbx$oHv7DpxbAuLIXMJlUI3xp0
1 Like
11

Thanks - have added that to my PR!

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.