Re: the need for a discoverable sub-volumes specification

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Mi, 10.11.21 10:34, Topi Miettinen (toiwoton@xxxxxxxxx) 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.

> 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.

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?

Lennart

--
Lennart Poettering, Berlin