[OpenWrt-Devel] ubus acls for params or hotplugd ?

[Etienne Champetier]

Hi all,

Le dim. 19 avr. 2020 à 20:16, Etienne Champetier
<champetier.etienne at gmail.com> a écrit :
>
> Hi all,
>
> Most OpenWrt daemon are still running as root today.
> If we take the case of ntpd, to do its job it just need CAP_SYS_TIME
> and to be able to deliver a hotplug event.
> Right now hotplug-call is a simple shell loop executing all the
> scripts in /etc/hotplug.d/$1/, so ntpd need to run as root.
>
> I would like to have this hotplug call go over ubus, and I see 2 ways:
> 1) either extend ubus acl to validate params, then have a generic exec
> functionality to basically have a sudo via ubus (really flexible but
> not super clean)
> 2) or have a small hotplugd that publish one path per type (ie have
> 'hotplug.ntp' with an 'event' method)
>
> Similarly to ntpd, udhcpc and odhcp6c don't require much capabilities
> (at most CAP_NET_RAW, CAP_NET_BIND_SERVICE) if we send the dhcp events
> as hotplug events over ubus.
>
> As some of you might already have ideas on this topic, I'm sending
> this email to get feedback how you would see this implemented (1, 2 or
> ...)

I had a good chat with Jow today on IRC and here is a sum up.
What we agree on:
- extending acl to filter on params would slow down ubus in the
default case and complicate the code, so it's better to have a
path/namespace per type
- we should extend procd instead of having a separate 'hotplugd' deamon
- this new mechanism should be smart enough to detect new event type at runtime
- the event params are untrusted, when converting them to environment
variables, we either need to whitelist them, to prefix them or a
combination of both.
If prefixing we need to ensure the name is a valid identifier
([^a-zA-Z0-9_]+) or reject the full request
- we should only support basic types for params (numbers / strings /
bool) and no nesting

What need more discussion:
- if we don't whitelist all currently used variables for hotplug
events, we need to adapt all current hotplug scripts. This means
potential breakage for OpenWrt derivatives.
(if multiple devs are fine with it I'm also fine)
- hotplug semantic is fire and forget, ie you don't expect a return
code, but for cases like udhcpc / odhcp6c the return code might be
important, and we don't really want to execute multiple scripts
(we could have /etc/hotplug.d/script ?)
- threading model, I was thinking only 1 exec at a time per type to be
on the safe side

Comments welcome
Etienne

>
> Thanks
> Etienne

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel