Current user on Linux stack is a root

Question & Answer Builds
1

Bitrise Build Issue Report template

Description of the issue

User which invokes bitrise CLI on Linux stack is a root (uid 0). It is not the case on macOS stacks. Is it intended difference?

Environment:

bitrise.io and locally using docker.

Which build Step causes the issue and which version of the step?
N/A

Reproducibility

  • Does a “Rebuild” help? (You can trigger a rebuild from the Build’s page, by clicking the “Rebuild” button in the top right corner of a finished build) : NO
  • Does a rebuild without caches help? (You can remove the Cache:Pull and Cache:Push steps temporarily to not to use the cache, or you can delete all the caches on the Settings tab of the app. : NO
  • If you have multiple different build configurations (workflows), does the issue affect all/more than one? : NO
  • If it’s an issue which happens sporadically, what’s the frequency? (e.g. Once a day ; about x% of the builds) : 100%
  • Does upgrading the build Step to the latest version help? : NO
  • When did the issue start? : existing from the beginning

Linux/Android stack builds

_Can it be reproduced by running the build locally, after doing a new git clone of the repository into the /tmp directory and running the build from there with the Bitrise CLI ( https://www.bitrise.io/cli )?: YES

Other stacks

Can it be reproduced by running the build locally with our CLI ( https://www.bitrise.io/cli ), after doing a new git clone of the repository into the /tmp directory and running the build from there with the Bitrise CLI ( https://www.bitrise.io/cli )?: it is not an issue on macOS stack, non-root user is used there.

Build log

Output of id on Linux stack:
uid=0(root) gid=0(root) groups=0(root)
on macOS stack:
uid=501(vagrant) gid=20(staff) groups=20(staff),701(com.apple.sharepoint.group.1),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh)

2

Yes it kind of is. Mainly because: on macOS it’s really rare to do anything as root. When needed sudo can be invoked but no app is designed to work as root and it’s overall not the best idea to use macOS as root.

On the other hand on Linux servers, and especially in/using Docker, using the root user is quite common. Docker did not have any other option for a long time, only root (inside the container).

The idea for the bitrise.io build VMs is to make them as close to a developer’s local environment as possible. On macOS that’s pretty much never a root user. Using Docker, for a long time it always was the case. Nowadays it’s possible to use a non root user in a docker container, but I’d say still the most common setup is to use root inside the container (which is the default).

1 Like
3

OK, thanks for the explanation.

I worked this issue around with the following bash script:

useradd -m bitrise
chown -R bitrise .
chown -R bitrise ${ANDROID_HOME}
su -c './gradlew check --scan' bitrise

In this case instead of Gradle Unit test step.

Do you recommend anything better?
Changing stack to something with macOS works but step like above is noticeably slower there.

PS

I don’t think that most of Android developers work on root user normally. I guess that Linux stack is mainly used for native Android projects, isn’t it?
On the other hand it seems that most of the workflows in such projects should work no matter if executed by root or not.

1 Like
4

Exactly.

You’re right. It’s a bit of a mixed bag, if someone uses Docker it’s more likely that the user will be root but if you don’t use Docker then indeed the user is less likely root.

Thanks for sharing the script! I’m sure it’ll help others too :wink:

5

Just one more question: may I ask why does it matter whether the user is root or not in your case? In case of Android it should not matter, but I probably miss something.

6

The reason was included in on-site chat from which this thread is originating from but forgot to copy it here, sorry.

Basically, there are unit tests which revoke unix file permissions to simulate unreadable or unwritable files and then checks if such state was handled properly. Such tests won’t pass under root because he can always read or write files, no matter if he has unix file permissions or not.

1 Like
7

Got it, thank for the info @koral!

I’m just curious, are those Android / mobile app unit tests? Or another project type?

8

Yes they are local unit tests of Android app so they are executed on the VM not on the device/emulator.

1 Like
9

Interesting issue regarding the file permission, but I’ll add my 2 cents why it’s great to have root on the CI (either by design or not)

On some past application we had to use some binaries that were not natively installed on the stack, so it was easy from a shell script to invoke sudo apt-get install or to chmod +x without issues

1 Like
10

Regular user added to sudoers/wheel is not the same thing as being logged in as root.
If you are logged in as root using sudo is not required.
Having user which is able to use sudo is of course useful, this is how it works on macOS stack.

This issue is only about executing bitrise CLI as root by default.

1 Like
11

Makes sense and I agree with both of you @koral & @sb_ronaldopace!

If you’d want us to change it @koral please create a #feature-request so that we can prioritize it.

12

I believe it is acceptable for us to use script step like that: Current user on Linux stack is a root. It is not so common case.
Apart from that I have no votes left :wink:

1 Like
13

Indeed I think it makes sense to have it that way, as a Script; maybe a short #how-to if you have some time @koral, but probably this discussion should be enough for others, as a reference :slight_smile:

P.S.: you can create #feature-request s even if you don’t have votes left, it’ll just start at 0 votes.

14

Here is a how to: How to simulate file I/O errors for testing purposes

1 Like
15

Thanks again for the #how-to @koral! :slight_smile: