<div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>any objections about distro feature flag to cover root Vs. non-root configs & code?</div><div><br></div><div>Thanks.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Oct 2020 at 13:22, Anton Kachalov <<a href="mailto:rnouse@google.com">rnouse@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>so, I'm ending up at the moment with an idea for this specific case of migration from root "space" to unprivileged. The idea is simple: cover config files and compile-time chunks of code to be covered by distro feature flag. This flag should be enabled for qemuarm target and then iteratively enabled across other platforms once they are ready. The rollback from non-root permissions back to root is painless and easy to achieve. No actual migration scripts should be required, just config changes.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Oct 2020 at 23:01, Anton Kachalov <<a href="mailto:rnouse@google.com" target="_blank">rnouse@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello, Patrick.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 16 Oct 2020 at 22:25, Patrick Williams <<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 14, 2020 at 08:47:57PM +0200, Anton Kachalov wrote:<br>
> With moving from root-only environment to unprivileged users' space, we<br>
> need to ensure a smooth transition. To achieve that we need a mechanism for<br>
> one-shot per-package scripts that would take care of migration. That's not<br>
> only about groups & owners, but a general approach. It's similar to<br>
> firstboot, but has a different purpose.<br>
> <br>
> I'm going to prototype a robust / naive solution to start a service before<br>
> everything else in the system with a condition (non-empty /etc/migration.d)<br>
> and iterate through all files. Each script has to run at list with "set -e"<br>
> to bail out on failures. If the script succeeded -- it will be removed.<br>
> <br>
> The tricky part is: what if the script fails? Keep it, ignore the failure<br>
> and proceed with others and then boot the system? Or proceed other scripts<br>
> as well and then enter some "failure state"?<br>
<br>
Hi Anton,<br>
<br>
I have some high-level questions / ideas about this.<br>
<br>
* Would these migrations be restricted to just useradd/groupadd operations? Or<br>
are you trying to create a general framework for "upgrade scripts"?<br></blockquote><div><br></div><div>This might be a general framework.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Have you looked at any existing support by Yocto or systemd to provide<br>
what you need? Yocto has USERADD_PACKAGES, postinst_intercept.<br>
Systemd has firstboot. There might be other mechanisms I'm not<br>
remembering as well. (I guess you mentioned firstboot). There is<br>
hacky override to install a "@reboot" directive in the crontab.<br></blockquote><div><br></div><div>afaik, systemd's firstboot is only about to run special units right after installation. Once the system is configured, the firstboot units wouldn't be executed anymore.</div><div>This thread I've started to find possible solutions.</div><div>The postinst chunks executed during the image formation (as a part of rpm / deb packages' scripts).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* How long would a "migration" be kept around for? Are we expecting<br>
that packages provide them forever?<br></blockquote><div><br></div><div>That is a good question because we don't know how old the firmware is being upgraded. I suppose, that like one-two-whatever release cycles. Then the update process should be either using an intermediate firmware version or forcing the non-volatile storage to be wiped. Regardless of the migration scripts, we might have some incompatibilities between two releases that will require NV (overlayfs back partition) cleanup.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* How do we handle downgrades? Some systems are set up with a "golden<br>
image" which is locked at manufacturing. Maybe simple<br>
useradd/groupadd calls are innately backwards compatible but I worry<br>
about a general framework falling apart.<br></blockquote><div><br></div><div>In general, that's an issue. Golden-image downgrades should be allowed within a compatible release branch (without wiping data). As above, golden-images might be incompatible and wouldn't allow downgrades.</div><div><br></div><div>The particular migration from root-only users to unprivileged users should be one way without wiping data. If the downgrade is requested, then it will be required to wipe the data.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Is there some mechanism we should do to run the migrations as part of<br>
the upgrade process instead of waiting to the next boot? The<br>
migrations could be included in the image tarball and thus be signed.<br>
That would save time on reboots for checking if the migrations are<br>
done.<br></blockquote><div><br></div><div>Yes, it could be done as a set of scripts during the update process. That is one of the possible approaches. This also could be an approach for downgrades. I'm only worrying about the effort to support downgrades from random version to random version. The least effort with incompatible upgrades / downgrades is to keep special transition firmware allowing downgrade from current Golden version to the previous Golden version from incompatible branch. For upgrades the latest version of transition firmware might not be golden. This will require a separate repo with an auto-generated set of scripts to be used to build transition fws.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Rather than have a single migration script that runs before everything<br>
else (and is thus serial), you might create a template service<br>
(phosphor-migration-@.service) that can be depended on by the services<br>
needing the migration results. (ie. service foo depends on<br>
migration-foo).<br></blockquote><div><br></div><div>While migration is one-off, it might be safer to run serial one by one.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* In a follow up email you mentioned something about hashing. I was<br>
going to ask how you know when a particular migration has been<br>
executed. Maybe there are some tricks of recording hash values in<br>
the RWFS could prevent multiple executions.<br></blockquote><div><br></div><div>We can track the succeeded scripts by touching some file in a directory like /var/lib/migration (e.g. create a file named as sha-sum of the runned script).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Patrick Williams<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>