New issue
Advanced search Search tips

Issue 834445 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 873164
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

enewgroup function fails to create user in /etc/group if it exists in /build/$BOARD/etc/group

Project Member Reported by mortonm@chromium.org, Apr 18 2018

Issue description

Code: https://cs.corp.google.com/chromeos_public/src/third_party/eclass-overlay/eclass/user.eclass?rcl=590ac1932044a530115017ceae64cb57ceadbc69&l=414

Calling enewgroup in .ebuild file should create that group in /etc/group, even if that group already exists in /build/$BOARD/etc/group. Currently this is not the case, causing emerge-$BOARD calls to fail when the .ebuild file needs to reference a group that already exists in the system.

P.S. not sure if only non-cros-workonable .ebuild files go off of /etc/group rather than /build/$BOARD/etc/group

P.P.S. not sure if the same problem exists for enewuser

 
Description: Show this description
Project Member

Comment 2 by bugdroid1@chromium.org, Apr 20 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/e53449ac8dd22ac152661751546834fa146298e2

commit e53449ac8dd22ac152661751546834fa146298e2
Author: Micah Morton <mortonm@chromium.org>
Date: Fri Apr 20 19:57:12 2018

Skip checks for user/group existence in user.eclass

These checks cause enewuser/enewgroup calls to fail if the user/group
already exists in the board sysroot but not in the sdk root. Sometimes
users/groups need to be created in the sdk root when they already exist
in the board sysroot. For example, in order to chown a file to user
'shill' in the ebuild for strongswan, 'shill' group needs to be created
in the sdk root at the same time that it already exists in the board
sysroot. This situation arises because the shill ebuild creates the
shill user/group during pkg_preinst() (so they are created in the board
sysroot only) but the strongswan ebuild needs to create the shill
group during pkg_setup() (which creates the group in the sdk root as
well).

_write_entry_to_db() checks whether entries in the group or passwd file
exists before adding the entries, so these checks are not necessary in
the first place.

BUG= chromium:834445 
TEST=before: cannot reference shill group in ebuild for strongswan, even
after calling enewgroup, after: can reference shill group

Change-Id: I2f1f9400ab8d9be615bdb56279ebddf4926b2557
Reviewed-on: https://chromium-review.googlesource.com/1017860
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Micah Morton <mortonm@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/e53449ac8dd22ac152661751546834fa146298e2/eclass/user.eclass

Project Member

Comment 3 by bugdroid1@chromium.org, Apr 22 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88

commit 03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88
Author: Manoj Gupta <manojgupta@chromium.org>
Date: Sun Apr 22 10:54:35 2018

Revert "Skip checks for user/group existence in user.eclass"

This reverts commit e53449ac8dd22ac152661751546834fa146298e2.

Reason for revert: Breaking chromiumos-sdk builder.
https://uberchromegw.corp.google.com/i/chromiumos/builders/chromiumos-sdk/builds/8715

BUG= chromium:835616 

Original change's description:
> Skip checks for user/group existence in user.eclass
>
> These checks cause enewuser/enewgroup calls to fail if the user/group
> already exists in the board sysroot but not in the sdk root. Sometimes
> users/groups need to be created in the sdk root when they already exist
> in the board sysroot. For example, in order to chown a file to user
> 'shill' in the ebuild for strongswan, 'shill' group needs to be created
> in the sdk root at the same time that it already exists in the board
> sysroot. This situation arises because the shill ebuild creates the
> shill user/group during pkg_preinst() (so they are created in the board
> sysroot only) but the strongswan ebuild needs to create the shill
> group during pkg_setup() (which creates the group in the sdk root as
> well).
>
> _write_entry_to_db() checks whether entries in the group or passwd file
> exists before adding the entries, so these checks are not necessary in
> the first place.
>
> BUG= chromium:834445 
> TEST=before: cannot reference shill group in ebuild for strongswan, even
> after calling enewgroup, after: can reference shill group
>
> Change-Id: I2f1f9400ab8d9be615bdb56279ebddf4926b2557
> Reviewed-on: https://chromium-review.googlesource.com/1017860
> Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
> Tested-by: Micah Morton <mortonm@chromium.org>
> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
> Reviewed-by: Mike Frysinger <vapier@chromium.org>

Bug:  chromium:834445 
Change-Id: Id6e5ba1da72b16f7258ad486c335b7fed4c00327
Reviewed-on: https://chromium-review.googlesource.com/1023163
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>

[modify] https://crrev.com/03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88/eclass/user.eclass

Cc: mortonm@chromium.org manojgupta@chromium.org
Unfortunately, I had to revert this CL because it caused chromiumos-sdk builder to fail. 

Please, test changes that affect SDK with a chromiumos-sdk tryjob.
Or to repro locally, use $ cros_sdk --bootstrap
Status: WontFix (was: Untriaged)
I've run into the same issue (see  https://crbug.com/873164 ) and I'm trying a slightly different fix (see CL:1170839). cros_sdk --bootstrap doesn't seem to do anything (with or without the patch). I've run the chromiumos-sdk tryjob:

https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8938305666688756640

How exactly did it fail? It's been running for a while now and so far no failure, but it seems to be taking an inappropriate amount of time:


I think the answer here is extremely simple even though it took me a while to figure out. When emerging a package to the SDK root (a.k.a. in pkg_setup) you need to do 'sudo emerge <package>' instead of 'emerge-$BOARD <package>'. That's what fixed this for me anyway.
I'll try to page the rest of this topic back in if there's more to this and that doesn't fix it. I spent an embarrassing amount of time on it so I definitely have the context if we need to discuss further.
I think I already tried what you're doing in CL:1170839:

https://chromium-review.googlesource.com/c/chromiumos/overlays/eclass-overlay/+/1048309
Cc: ljusten@chromium.org
Re #7:
Alternatively,
  nano /build/${board}/etc/passwd (or group)
and remove the entry, then emerge-${BOARD} your project.

But will this work on the buildbots as well? I'm concerned that the CL would break any bots that don't rebuild everything from scratch every time.

Re #10:
Ah yes, that's almost equivalent to my CL. My CL does a little more conservative and won't put stuff into passwd or group if it's already there.

Mergedinto: 873164
Status: Duplicate (was: WontFix)

Sign in to add a comment