Ignition creates containing directories for files/dirs/links specified in the config, but it gives them default ownership/permissions rather than the ones specified for the file/dir/link. This ensures that containing directories have safe default ownership. It's still possible to override the parents' ownership/perms by explicitly specifying the containing directories in the directories section.
But it's not especially ergonomic. A deeply-nested file might need several containing directories, each of which needs to be spelled out explicitly. This makes sense for Ignition configs, which are intentionally low-level, but it'd be nice to have Butane sugar to avoid this.
The main issue here will be syntax. Butane doesn't know which directories already exist, and we can't override perms on every containing directory all the way up to the root. For example, if creating /home/builder/.config/systemd/user/default.target.wants/something.service, we might want to set ownership for builder/.config/systemd/user/default.target.wants but not /home. I don't think the ecosystem has a conventional syntax for this.
That has the disadvantages of being verbose and difficult to understand.
We could merge the "parent directories" fields into the files/directories/links sections, but we can't reuse a file mode as a directory mode, so we might want another field or so:
Ignition creates containing directories for files/dirs/links specified in the config, but it gives them default ownership/permissions rather than the ones specified for the file/dir/link. This ensures that containing directories have safe default ownership. It's still possible to override the parents' ownership/perms by explicitly specifying the containing directories in the
directories
section.But it's not especially ergonomic. A deeply-nested file might need several containing directories, each of which needs to be spelled out explicitly. This makes sense for Ignition configs, which are intentionally low-level, but it'd be nice to have Butane sugar to avoid this.
The main issue here will be syntax. Butane doesn't know which directories already exist, and we can't override perms on every containing directory all the way up to the root. For example, if creating
/home/builder/.config/systemd/user/default.target.wants/something.service
, we might want to set ownership forbuilder/.config/systemd/user/default.target.wants
but not/home
. I don't think the ecosystem has a conventional syntax for this.We could do something like this:
That has the disadvantages of being verbose and difficult to understand.
We could merge the "parent directories" fields into the
files
/directories
/links
sections, but we can't reuse a file mode as a directory mode, so we might want another field or so:Discussion thread