cloud-init-dev team mailing list archive

[Dimitri John Ledkov <launchpad@xxxxxxxxxxxx>]

Review: Needs Information

Reading the bug report, and this merge proposal, I am slightly concerned and would want to more information.

Ec2Local datasource is called "local" yet it clearly brings network up. Can you explain a bit how it works? Does it discover something else behind dhcp and chain loads something else? Instead of dhclient can it generate "dhcp first interface" netplan config and use that to bring networking up? Note that default dhcp client in artful and up is simply systemd-networkd internal implementation. It would be interesting to see if cloud-init can switch to that away from dhclient.

The security issue concerns me a lot of how dhclient is run. It seems like you are hitting default ubuntu security policy and trying to circumvent that. In particular, why can you not run /sbin/dhclient from where it is, and use /run/ configs / auxiliary files for it? Do we need to bring in security team to assist in operating dhclient safely and in a simple manner? Imho executing /sbin/dhclient as root, and pointing it to use state files in /run is still architecturally right solution, even if we need to change apparmor policy etc. If need be, we can even ship a custom systemd dhclient-cloud-init.service which will self create /run directories and self-apply an appropriate apparmor profile which e.g. Ec2Local can start if and when needed.
-- 
https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330875
Your team cloud-init commiters is requested to review the proposed merge of ~chad.smith/cloud-init:dhclient-from-var-tmp into cloud-init:master.