Feature #5684: Create osmocom user via OE recipe - Cellular Network Infrastructure - Open Source Mobile Communications

Custom queries

all-by-project

Actions

Copy link

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 about 1 year ago.

Status:

Rejected

Priority:

Normal

Assignee:

osmith

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.

History
Notes
Property changes

Actions

Copy link

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

Copy link

Updated by msuraev over 1 year ago

Status changed from New to In Progress
Assignee set to msuraev

Actions

Copy link

Updated by msuraev over 1 year ago

% Done changed from 0 to 10

https://gerrit.osmocom.org/c/meta-telephony/+/29476 - WIP

Actions

Copy link

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

Copy link

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

Copy link

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

Copy link