17:49 < champtar> Hi all, I'm thinking about having hotplug call go over ubus, but not sure how to go about it, either have a method per type (hotplug.ntp), or extending ubus acl to be able to validate arguments (service.event type: hotplug.ntp)
17:51 < champtar> the goal would be to finally sandbox all the daemons running as root like ntpd / udhcpc / odhcp6c that need very few privileges execpt to call hotplug
19:29 < jow> aparcar[m]: sqlite
22:06 < champtar> karlp: yes, ntpd for example
22:06 < champtar> karlp: yes the "producers", ntpd for example
19:41 < jow> I don't get it :(
19:42 < champtar> jow: you don't get why parsing untrusted network data shoudn't be done as root ?
19:42 < champtar> :P
19:42 < jow> champtar: that I do. I dont understand why hotplug is a problem and how using ubus would solve it
19:42 < jow> especially since relying on ubus would require a lot more C handling code to be written
19:44 < champtar> if ntpd run as 'ntp' user, the hotplug scripts will run as 'ntp' user
19:44 < champtar> blogic: ambient capabilities
19:44 < jow> ah, so you want to repalce the hotplug "bus"
19:44 < champtar> yes, right now there is no bus
19:45 < jow> well
19:45 < jow> so you need something subscribing to kernel uevents and broadcasting them to ubus
19:46 < champtar> nop
19:46 < champtar> I still want to have ntpd call a small script
19:46 < jow> and you need to modify hotplug-call xxx to invoke ubus send hotplug '{ "class": "xxx" }'
19:47 < champtar> but have acl to allow only the type / class hotplug.ntp
19:47 < jow> and whatever process is hosting the ubus hotplug namespace then eeds to invoke the scrptlets in /etc/hotplug.d/
19:47 < champtar> jow: yes
19:48 < champtar> but it needs to also work for udhcpc
19:51 < jow> so in the end its a kind of suid + command filter mechanism
19:51 < champtar> I also want to be able to run ntpd in an almost empty ujail
19:52 < champtar> with a suid you would need the whole /etc/hotplug.d/ and many dependencies
19:52 < jow> why not simply let ntpd broadcast an event (something similar to ubus call service event, just more generalized) and have whatever is interested in it simply handle it?
19:53 < jow> e.g. a reload trigger for dnsamsq
19:53 < champtar> we need to filter the type of events that ntpd can generate
19:54 < jow> that should be doable already
19:54 < champtar> jow: we only filter on method, not params in the acls
19:54 < jow> iirc ubus supports acl's that can be tied to the remote socket user credentails (effective uid)
19:54 < jow> so the acl mechanism needs to be extended
19:55 < champtar> thus the title of my email "ubus acls for params or hotplugd ?" ;)
19:55 < jow> filter on param does not scale well imho, better break out the event type out of the param and make it part of the namespace / method or whatever
19:56 < jow> you would need to unmarshall the params blob just to apply potential acl rules on it
19:56 < jow> this will slow down the common path for anything using ubus
19:58 < champtar> jow: I would like to just drop an handler script, /etc/ubus-handler.d/hotplug.ntp
19:58 < jow> champtar: your proposed option 2 sounds like the way to go
19:59 < jow> publish one namespace per hotplug event class
19:59 < jow> apply ACLs on the per-class namespaces
19:59 < champtar> and have the hotplug.ntp namespace be usable
19:59 < champtar> yup but do I want another daemon for that
20:00 < jow> no, preferably it should go into procd / plugd or whatever sits on the kernel uevent socket atm
20:03 < jow> champtar: the ubus hotplug machinery would need to go into this part of procd: https://lxr.openwrt.org/source/procd/plug/hotplug.c
20:03 < jow> champtar: and it needs to be smart enough / provide a mechanism to update the namespaces at runtime
20:04 < jow> e.g. some /etc/hotplug.d/xxx class might not exist on boot but might be added later when an installed package stages stuff there
20:07 < jow> m4t: yeah, I use them all the time
20:08 < jow> combined-squash
20:14 < jow> m4t: https://pastebin.com/ZQWQrJdQ
20:29 < jow> yeah
20:29 < jow> at some point we lost the default padding in x86 squash images, making them unusable
20:30 < jow> ... ootb as vm image
21:02 < champtar> jow: we still need something to validate the params of the event, as it's untrusted, so what do you think of script handlers in /etc/ubus-handler.d/ ?
21:03 < champtar> with procd doing all the "publishing" work
21:12 < jow> champtar: not much
21:13 < jow> why do we need to validate params?
21:14 < jow> what is the thread model, what untrested input do we need to guard against?
21:14 < jow> I wouldn't expect even params to carry e.g. shell commands
21:14 < jow> *event params
21:21 < champtar> right now most hotplug params end up being environement variables
21:22 < champtar> we need to safely transform the data table in the event in the right command
21:23 < jow> you could apply generic constraints
21:23 < jow> like disallow nested / complex values in event args (so only u32, u8, string, bool, no object/array)
21:23 < jow> when transforming the fields into env vars, forcibly prefix them
21:23 < jow> to prevent things like overwriting $PATH
21:24 < jow> (and u8 == bool)
21:25 < jow> field names could be either transformed into valid shell identifiers doing something like s/[^a-zA-Z0-9_]+/_/g
21:25 < jow> or rejected outright
21:25 < champtar> I prefer to reject
21:26 < jow> fine with me
21:26 < champtar> and to prefix
21:26 < champtar> but then we need to change the hotplug
21:26 < champtar> hotplugs*
21:26 < jow> that is an acceptable tradeoff
21:28 < champtar> and the generic handler script seems to be the same amount of work that only handling hotplug