rnouse at google.com
Fri Oct 23 03:19:20 AEDT 2020
any objections about distro feature flag to cover root Vs. non-root configs
On Tue, 20 Oct 2020 at 13:22, Anton Kachalov <rnouse at google.com> wrote:
> 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
> On Fri, 16 Oct 2020 at 23:01, Anton Kachalov <rnouse at google.com> wrote:
>> Hello, Patrick.
>> On Fri, 16 Oct 2020 at 22:25, Patrick Williams <patrick at stwcx.xyz> wrote:
>>> On Wed, Oct 14, 2020 at 08:47:57PM +0200, Anton Kachalov 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
>>> > only about groups & owners, but a general approach. It's similar to
>>> > firstboot, but has a different purpose.
>>> > I'm going to prototype a robust / naive solution to start a service
>>> > everything else in the system with a condition (non-empty
>>> > 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 tricky part is: what if the script fails? Keep it, ignore the
>>> > and proceed with others and then boot the system? Or proceed other
>>> > as well and then enter some "failure state"?
>>> Hi Anton,
>>> I have some high-level questions / ideas about this.
>>> * Would these migrations be restricted to just useradd/groupadd
>>> operations? Or
>>> are you trying to create a general framework for "upgrade scripts"?
>> This might be a general framework.
>>> * Have you looked at any existing support by Yocto or systemd to provide
>>> what you need? Yocto has USERADD_PACKAGES, postinst_intercept.
>>> Systemd has firstboot. There might be other mechanisms I'm not
>>> remembering as well. (I guess you mentioned firstboot). There is
>>> hacky override to install a "@reboot" directive in the crontab.
>> 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.
>> This thread I've started to find possible solutions.
>> The postinst chunks executed during the image formation (as a part of rpm
>> / deb packages' scripts).
>>> * How long would a "migration" be kept around for? Are we expecting
>>> that packages provide them forever?
>> 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.
>>> * How do we handle downgrades? Some systems are set up with a "golden
>>> image" which is locked at manufacturing. Maybe simple
>>> useradd/groupadd calls are innately backwards compatible but I worry
>>> about a general framework falling apart.
>> 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.
>> 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.
>>> * Is there some mechanism we should do to run the migrations as part of
>>> the upgrade process instead of waiting to the next boot? The
>>> migrations could be included in the image tarball and thus be signed.
>>> That would save time on reboots for checking if the migrations are
>> 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.
>>> * Rather than have a single migration script that runs before everything
>>> else (and is thus serial), you might create a template service
>>> (phosphor-migration- at .service) that can be depended on by the services
>>> needing the migration results. (ie. service foo depends on
>> While migration is one-off, it might be safer to run serial one by one.
>>> * In a follow up email you mentioned something about hashing. I was
>>> going to ask how you know when a particular migration has been
>>> executed. Maybe there are some tricks of recording hash values in
>>> the RWFS could prevent multiple executions.
>> 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
>>> Patrick Williams
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc