[systemd-devel] the need for a discoverable sub-volumes specification

[Topi Miettinen]

On 11.11.2021 19.27, Lennart Poettering wrote:
> On Mi, 10.11.21 10:34, Topi Miettinen (toiwoton at gmail.com) wrote:
> 
>>> Doing this RootDirectory= would make a ton of sense too I guess, but
>>> it's not as obvious there: we'd need to extend the setting a bit I
>>> think to explicitly enable this logic. As opposed to the RootImage=
>>> case (where the logic should be default on) I think any such logic for
>>> RootDirectory= should be opt-in for security reasons because we cannot
>>> safely detect environments where this logic is desirable and discern
>>> them from those where it isn't. In RootImage= we can bind this to the
>>> right GPT partition type being used to mark root file systems that are
>>> arranged for this kind of setup. But in RootDirectory= we have no
>>> concept like that and the stuff inside the image is (unlike a GPT
>>> partition table) clearly untrusted territory, if you follow what I am
>>> babbling.
>>
>> My images don't have GPT partition tables, they are just raw squashfs file
>> systems. So I'd prefer a way to identify the version either by contents of
>> the image (/@auto/ directory), or something external, like name of the image
>> (/path/to/image/foo.version-X.Y). Either option would be easy to implement
>> when generating the image or directory.
> 
> Hmm, so thinking about this again, I think we might get away with a
> check "/@auto/ exists and /usr/ does not". i.e. the second part of the
> check removes any ambiguity: since we unified the OS in /usr it's an
> excellent way to check if something is or could be an OS tree.
> 
> That said: naked squashfs sucks. Always wrap your squashfs in a GPT
> wrapper to make things self-descriptive.

It would be an extra step in image making process. I think naming the 
images '*.squashfs' documents them well enough for me.

>> But if you have several RootDirectories or RootImages available for a
>> service, what would be the way to tell which ones should be tried if there's
>> no GPT? They can't all have the same name. I think using a specifier (like
>> %q) would solve this issue nicely and there wouldn't be a need for /@auto/
>> in that case.
> 
> A specifier is resolved at unit file load time only. It wouldn#t be the
> right fit here, since we don#t want to require that the paths
> specified in RootDirectory=/RootImage= are already accessible at the
> time PID 1 reads/parses the unit file.

Well, that's out then.

> What about this: we could entirely independently of the proposal
> originally discussed here teach RootDirectory= + RootImage= one magic
> trick: if the path specified ends in ".auto.d/" (or so) then we'll not
> actually use the dir/image as-is but assume the path refers to a
> directory, and we'd pick the newest entry inside it as decided by
> strverscmp().
> 
> Or in other words, we'd establish the general rule that dirs ending in
> ".auto.d/" contains versioned resources inside, that we could apply
> here and everywhere else where it fits, too.
> 
> of course intrdocuing this rule would be kind of a compat breakage
> because if anyone happened to have named their dirs like that already
> we'd suddenly do weird stuff with it the user might not expect. But I
> think I could live with that.
> 
> A patch for that should be pretty easy to do, and be very generically
> useful. I kinda like it. What do you think?

Yes, that could work. I'd need to rename the LVM VG to 'levy.auto.d' 
(maybe instead create a new VG just for these images) and the directory 
too but that's no problem.

-Topi