Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile switches to daemon user uid instead of the daemonUser #1198

Closed
kunalkapoor opened this issue Feb 6, 2019 · 1 comment
Closed

Comments

@kunalkapoor
Copy link

With the addition of the new docker permission model to use Multi-stage dockerfiles (34c776d), the user switching does not work as expected.

Expected behaviour

Earlier, sbt docker:stage used to do the following

val user = (daemonUser in Docker).value
makeUser(user)

This creates the following Dockerfile

USER daemon

There was no check to ensure the "daemon" user exists or not.

Actual behaviour

Now, the code does this

val user = (daemonUser in Docker).value
val uid = 1001
makeUserAdd(user, uid, gid)
makeUser(uid)

makeUserAdd adds the "daemon" user if it doesn't exist and then the makeUser switches to that user. However, if the "daemon" user does exist and with a different uid than that hardcoded 1001, then the makeUser switches to a uid that doesn't exist in the system.

The Dockerfile created looks like below

RUN id -u daemon || useradd --system --create-home --uid 1001 --gid 0 daemon
USER 1001

As you can see above, if the id -u daemon part returns a 0 exit code, then the daemon user already exists and is not created. In this case, if the daemon user has a uid other than 1001, then USER 1001 essentially switches to a user that does not exist.

Solution

  1. The makeUser(uid) code in stage1 needs to be makeUser(user) to ensure we switch to the daemon user and not be dependent on the uid.
  2. We should make the uid = 1001 a configurable parameter in build.sbt (just like daemonUser).

Information

  • What sbt-native-packager are you using
    1.13.17
  • What sbt version
    1.2.8
  • What is your build system (e.g. Ubuntu, MacOS, Windows, Debian )
    MacOS and CentOS
  • What package are you building (e.g. docker, rpm, ...)
    sbt docker:stage
  • What is your target system (e.g. Ubuntu 16.04, CentOS 7)
    MacOS and CentOS 7
kunalkapoor pushed a commit to kunalkapoor/sbt-native-packager that referenced this issue Feb 8, 2019
Refers sbt#1198.

In attempting to switch to the `daemonUser` we are instead switching to the hardcoded uid 1001. If the daemon user exists with a different uid then the docker container default user is incorrect. Correcting the `makeUser` function to switch to the username specified by `daemonUser` instead of the static uid.
@muuki88
Copy link
Contributor

muuki88 commented Feb 8, 2019

Thanks for the detailed report and the proposed PR. I'll take a look as soon as possible.

eed3si9n added a commit to eed3si9n/sbt-native-packager that referenced this issue Feb 8, 2019
Fixes sbt#1198

Numeric USER directive is now controlled using `daemonUserUid in Docker`, which defaults to `Some("1001")`.

To get back to previous behavior the following can be used:

```scala
daemonUserUid in Docker := None
daemonUser in Docker    := "daemon"
```
eed3si9n added a commit to eed3si9n/sbt-native-packager that referenced this issue Feb 8, 2019
Fixes sbt#1198

Numeric USER directive is now controlled using `daemonUserUid in Docker`, which defaults to `Some("1001")`.

To get back to previous behavior the following can be used:

```scala
daemonUserUid in Docker := None
daemonUser in Docker    := "daemon"
```
muuki88 pushed a commit that referenced this issue Feb 11, 2019
* Use daemonUserUid to opt-out of numeric USER

Fixes #1198

Numeric USER directive is now controlled using `daemonUserUid in Docker`, which defaults to `Some("1001")`.

To get back to previous behavior the following can be used:

```scala
daemonUserUid in Docker := None
daemonUser in Docker    := "daemon"
```

* Fix docker/volumes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants