/etc/migration.d

[Ed Tanous]

On Wed, Oct 14, 2020 at 11:49 AM Anton Kachalov <rnouse at google.com> wrote:
>
> With moving from root-only environment to unprivileged users' space, we need to ensure a smooth transition. To achieve that we need a mechanism for one-shot per-package scripts that would take care of migration. That's not only about groups & owners, but a general approach.

Are there other use cases that necessitate a general approach?  I'm
not against it, but owners and groups seems unique in the regard that
the migration has to run as root.  Most (all?) other migrations don't
seem to, or haven't in the past, and therefore can be run as a
pre-init, or as part of the service itself.  If the service itself
does the migration, the startup dependencies are a lot easier to track
as a maintainer, and running your migrations in a compiled language
likely has a positive effect on boot time, which has been a problem in
the past (still is depending on who you ask).

It should be noted, several apps have done simple migrations of config
file formats in the past, so there's some precedent for it, just not
in a generalist solution.

>  It's similar to firstboot, but has a different purpose.
>
> I'm going to prototype a robust / naive solution to start a service before everything else in the system with a condition (non-empty /etc/migration.d) and iterate through all files. Each script has to run at list with "set -e" to bail out on failures. If the script succeeded -- it will be removed.

The script itself will be removed?  Presumably that means you're
executing the script out of non-volatile?  That seems like a security
gap in that an attacker could inject migration scripts that did
anything, and have the system run them for them.  Maybe just keeping
some kind of external log of "these scripts have completed" or,
preferably, enforcing that migration scripts are idempotent would be
better, and would reduce the possibility of a bad actor getting
permanent execution privileges if they somehow overwrote the scripts?

>
> The tricky part is: what if the script fails? Keep it, ignore the failure and proceed with others and then boot the system? Or proceed other scripts as well and then enter some "failure state"?

Assuming you can have migrations that are interlinked, have to be run
in order, and sometimes can fail, maybe the "best" thing to do is to
simply stop on the failing one, and try to boot the system as well as
it's able to in the degraded state.  This would mean that flakey
scripts would be rerun on the next boot, and hopefully succeed, and
consistently failing scripts could be replaced on a subsequent
firmware update with more robust versions, and rerun.