Project

General

Profile

Actions

Feature #5684

closed

Feature #4107: Start systemd services as non-root user

Create osmocom user via OE recipe

Added by msuraev over 1 year ago. Updated 12 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/19/2022
Due date:
% Done:

10%

Spec Reference:

Description

There's a plan to transition running Osmocom services under osmocom:osmocom by default on supported distro. As a preparation step for that let's make sure that such user/group is baked into our OE images.

Actions #1

Updated by msuraev over 1 year ago

Note: we don't have to wait for service migration: having additional unused user:group with nologin in the image is not a burden.

Sample recipe: https://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb - not sure if it's better to add it to packagegroup-osmocom.bb or some other recipe.

Actions #2

Updated by msuraev over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to msuraev
Actions #3

Updated by msuraev over 1 year ago

  • % Done changed from 0 to 10
Actions #4

Updated by msuraev over 1 year ago

  • Assignee changed from msuraev to osmith

Note: we should create system user without password and shell, not a regular user which capable of logging in.

Corresponding parameters to adduser/useradd can be taken from any related patch, for example https://gerrit.osmocom.org/c/osmo-upf/+/29716

The open question is how/if we should deal with users upgrading existing images instead of reinstalling the new image with baked-in users. Should this be handled via eparate .opkg? Or perhaps osmo-* packages with non-root services should be included only into feeds for newly released images?

Actions #5

Updated by osmith over 1 year ago

  • Assignee changed from osmith to msuraev

The open question is how/if we should deal with users upgrading existing images instead of reinstalling the new image with baked-in users. Should this be handled via eparate .opkg? Or perhaps osmo-* packages with non-root services should be included only into feeds for newly released images?

We should definitely deal with that, in a way that users can just upgrade the packages and don't get any breakage.

I'm not that familiar with OE packaging, but I would assume that we can add the user in a package that is present on all systems, in post-install (for new installs) and post-upgrade (for existing installs) scripts. I'd put it in libosmocore, unless we have a more suitable package.

Actions #6

Updated by pespin over 1 year ago

osmith wrote in #note-5:

I'm not that familiar with OE packaging, but I would assume that we can add the user in a package that is present on all systems, in post-install (for new installs) and post-upgrade (for existing installs) scripts. I'd put it in libosmocore, unless we have a more suitable package.

Grep for "useradd" in any OE repository. Example:

inherit useradd
USERADD_PACKAGES = "${PN}" 
USERADD_PARAM_${PN} = "--system -g asterisk --shell /bin/false asterisk" 
GROUPADD_PARAM_${PN} = "--system asterisk" 

Find the bbclass implementing it here:
https://git.yoctoproject.org/poky/tree/meta/classes/useradd.bbclass?h=pyro

That should give you info on whether it's fine to have the user created on each recipe, or a new specific separate recipe has to be created to just create the user.
In any case I'd add that in libosmocore recipe. Either do so on each recipe for program expecting the user, or on a specific separate recipe/task (maybe just at image creation time).

Actions #7

Updated by msuraev over 1 year ago

  • Status changed from In Progress to Stalled
Actions #8

Updated by osmith about 1 year ago

  • Assignee changed from msuraev to osmith
Actions #9

Updated by osmith 12 months ago

  • Status changed from Stalled to Rejected

As discussed with Harald, we will keep the services running as root on the OE systems.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)