Call getpwuid only after chroot is set

[zedi-pramodh]

There is a regression in recent commit where getpwuid() was added before chroot is set. Due to that any container which runs with non-root userid will fail to start.

Testing done

Before this fix grafana container which runs with user id 472 was failing to start. It works with this fix.

[eriknordmark]

Can you add a reference to the commit/PR which caused the regression (so it is easier to track and to figure out if this fix needs to be back-ported).

[zedi-pramodh]

Yes this need to be back ported. I labeled as stable.

[zedi-pramodh]

commit 53e2d24
Author: Shahriyar Jalayeri shahriyar@zededa.com
Date: Wed Oct 25 10:16:56 2023 +0000

initrd : check for errors and do initgroups on chroot

check for errors on security sensitive calls and call initgroups() to remove
root from the new uid supplementary groups.

Signed-off-by: Shahriyar Jalayeri <shahriyar@zededa.com>

[rouming]

The original intention of the change was to be sure shim vm has the same user, but let @shjala review that.

My only request is please add a proper commit message describing the problem and what exact commit this fix targets. Thanks.

[zedi-pramodh]

Updated the commit message

[OhmSpectator]

What is the grafana container mentioned in the PR description? I've tried to find it in the scripts and cannot find it... Should it even use this util? I think the use case should be discussed with @shjala.

Until now the only use case that I'm aware about is here:

eve/pkg/xen-tools/initrd/init-initrd

Line 190 in 09aa0fe

eval /chroot2 /mnt/rootfs "${WORKDIR:-/}" $ug $pid_file $cmd 2>&1 | tee -i /dev/hvc0

[zedi-pramodh]

What is the grafana container mentioned in the PR description? I've tried to find it in the scripts and cannot find it... Should it even use this util? I think the use case should be discussed with @shjala.

Until now the only use case that I'm aware about is here:

I did not understand your comment. Customers can use any container image, grafana is just an app running in the container. It happens that it runs with non-root userid. You can check alpha for that image if you are interested.

[OhmSpectator]

Customers can use any container image, grafana is just an app running in the container.

So, is it just a regular container Application deployed on a node?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (2dcaf10) 19.69% compared to head (4e48fca) 19.72%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3742      +/-   ##
==========================================
+ Coverage   19.69%   19.72%   +0.02%     
==========================================
  Files         235      235              
  Lines       51708    51708              
==========================================
+ Hits        10185    10198      +13     
+ Misses      40782    40771      -11     
+ Partials      741      739       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zedi-pramodh]

So, is it just a regular container Application deployed on a node?

Yes.

[OhmSpectator]

So, it means EVE has been failing to run any container App since 11.3.0... Wow.
It's good that we do not have the original code in any stable/LTS branch, so no customer is affected, and the backports are not needed.
I still wanna understand how we use this chroot2 tool in Pillar... I didn't know we use it when starting apps. Looks hacky.
UPD... Argh... It's a part of the ramdisk that we use in any container app...

[OhmSpectator]

Another question: why our regression tests did not detect this problem... @uncleDecart, do you know whether we have any tests for the container-based apps?

[zedi-pramodh]

Its not all containers fail to start. Only containers that run the apps with non-root user. May be most of the test cases run the apps in the container as root user.

[eriknordmark]

Kick off tests; @shjala should review before we merge this.

[milan-zededa]

Another question: why our regression tests did not detect this problem... @uncleDecart, do you know whether we have any tests for the container-based apps?

@OhmSpectator It was detected but Shah is busy this week with high-priority TPM issues: lf-edge/eden#944

[eriknordmark]

Based on the discussion in lf-edge/eden#944 this fix is needed.
(And we need to get the eden tests to pass regularly to not miss a test failure like this in the noise of other stochastic failures.)