When it runs on each boot, specifically in the init stages (i.e. when the `cloud-init-local.service` and `cloud-init.service` systemd units run), cloud-init executes `ensure_file`[0] on `/var/log/cloud-init.log` and in so doing resets the permissions to 644.
I am fairly confident that this resetting of the permissions is not intentional; I can't think of a compelling reason to do that, so I expect we can stop doing it.
I believe the fix is fairly simple: `write_file` (which `ensure_file` uses) has a `preserve_mode` parameter which defaults to `False`. We should expose that in `ensure_file` and pass `preserve_mode=True` when calling `ensure_file` for `cloud-init.log`. Then it will be created
world-readable if it does not already exist, but its permissions will not be modified if it does.
When it runs on each boot, specifically in the init stages (i.e. when the `cloud- init-local. service` and `cloud- init.service` systemd units run), cloud-init executes `ensure_file`[0] on `/var/log/ cloud-init. log` and in so doing resets the permissions to 644.
I am fairly confident that this resetting of the permissions is not intentional; I can't think of a compelling reason to do that, so I expect we can stop doing it.
I believe the fix is fairly simple: `write_file` (which `ensure_file` uses) has a `preserve_mode` parameter which defaults to `False`. We should expose that in `ensure_file` and pass `preserve_ mode=True` when calling `ensure_file` for `cloud-init.log`. Then it will be created
world-readable if it does not already exist, but its permissions will not be modified if it does.
[0] https:/ /github. com/canonical/ cloud-init/ blob/master/ cloudinit/ util.py# L1807-L1808