[OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks

[Peter Kjellerstedt]

> -----Original Message-----
> From: Richard Purdie <richard.purdie at linuxfoundation.org>
> Sent: den 3 april 2019 14:48
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> exist for package_write_* tasks
> 
> On Wed, 2019-04-03 at 14:26 +0200, Peter Kjellerstedt wrote:
> > If the populate_lic task and any of the package_write_* tasks need to
> > run, but the package task can be restored from the sstate cache, then
> > the fetch task, which is a dependency of populate_lic, will wipe out
> > the RSS including any users/groups that have been created. This
> > results in that the package_write_* tasks are run without any
> > user/group information, which causes them to fallback to either use
> > the root user for any unknown users/groups (rpm) or to use the numeric
> > UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.
> >
> > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
> > ---
> >  meta/classes/useradd.bbclass | 18 ++++++++++++------
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
> > index 124becd082..e32315a1af 100644
> > --- a/meta/classes/useradd.bbclass
> > +++ b/meta/classes/useradd.bbclass
> > @@ -4,7 +4,7 @@ inherit useradd_base
> >  # target sysroot, and shadow -native and -sysroot provide the utilities
> >  # and support files needed to add and modify user and group accounts
> >  DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot shadow base-passwd"
> > -PACKAGE_WRITE_DEPS += "shadow-native"
> > +PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
> >
> >  # This preinstall function can be run in four different contexts:
> >  #
> > @@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
> >      task = d.getVar("BB_CURRENTTASK")
> >      if task == "package_setscene":
> >          bb.build.exec_func("useradd_sysroot", d)
> > -    elif task == "prepare_recipe_sysroot":
> > +    elif (task == "prepare_recipe_sysroot" or
> > +          task == "package_write_deb" or
> > +          task == "package_write_ipk" or
> > +          task == "package_write_rpm"):
> >          # Used to update this recipe's own sysroot so the user/groups are available to do_install
> >          scriptfile = d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
> >          bb.build.exec_func("useradd_sysroot", d)
> > @@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
> >          os.chmod(scriptfile, 0o755)
> >  }
> >
> > -do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > -SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> >  SYSROOTFUNC = ""
> > +SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> >
> > -SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > +do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > +do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
> > +do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
> > +do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
> >
> > -SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
> > +SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > +SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
> >
> >  do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
> >  do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
> 
> This may be a bigger problem that just package_write_*.
> 
> This feels like a bad thing to do since there may be other tasks which
> also rely on the user information being present. This probably only
> fixes one corner case but there are likey others :(.
> 
> Possible solutions might be:
> 
> a) To wipe out all sstate tasks if we're rerunning do_fetch

How to do that? With some pointers I hope I can whip up a patch 
to do this instead.

Is this rare or is it likely to cause a performance impact?
If it only happens in the cases where we are seeing problems due to 
the removed user/group info, then it should be reasonably rare.

> b) Preserve the user/group information around the cleaning of the
> sysroot

This sounds error prone at best...

> I think we may need to fix this generically...
> 
> Cheers,
> 
> Richard

//Peter