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

Use of su-exec now requires container be started as root #7773

Closed
jtackaberry opened this issue Jun 12, 2019 · 0 comments · Fixed by #7776
Closed

Use of su-exec now requires container be started as root #7773

jtackaberry opened this issue Jun 12, 2019 · 0 comments · Fixed by #7776

Comments

@jtackaberry
Copy link

As of RELEASE.2019-06-11T00-44-33Z, minio now fails to run in my environment. Regression ostensibly introduced by #7569.

# docker-compose  up
Recreating minio ...
Recreating minio ... done
Attaching to minio
minio    | su-exec: setgroups(1001): Operation not permitted
minio exited with code 1

Given this docker-compose.yaml:

minio:
 container_name: minio
 restart: always
 image: minio/minio:RELEASE.2019-06-11T00-44-33Z
 user: "1001:1001"
 command: minio server /data
 ports:
 - 9000:9000/tcp
 environment:
    HOME: /tmp
    MINIO_HTTP_TRACE: /data/minio.log
 volumes:
 - /home/minio/data:/data
 - /home/minio/config:/tmp/.minio

Here, Docker takes care of launching the container as uid 1001. Minio's attempt to drop privileges ironically fails because it starts unprivileged.

@harshavardhana harshavardhana self-assigned this Jun 12, 2019
harshavardhana added a commit to harshavardhana/minio that referenced this issue Jun 12, 2019
This allows MinIO containers to run properly without
expecting higher priviledges situations where following
styles are used

 - docker run --user uid:gid
 - docker-compose up (with docker-compose.yml with user)
 ```yml
 ...
 user: "1001:1001"
 command: minio server /data
 ...
 ```
 - All openshift containers

Fixes minio#7773
harshavardhana added a commit to harshavardhana/minio that referenced this issue Jun 12, 2019
This allows MinIO containers to run properly without
expecting higher priviledges in situations where following
restrictions on containers are used

 - docker run --user uid:gid
 - docker-compose up (with docker-compose.yml with user)
 ```yml
 ...
 user: "1001:1001"
 command: minio server /data
 ...
 ```
 - All openshift containers

Fixes minio#7773
harshavardhana added a commit to harshavardhana/minio that referenced this issue Jun 12, 2019
This allows MinIO containers to run properly without
expecting higher privileges in situations where following
restrictions on containers are used

 - docker run --user uid:gid
 - docker-compose up (with docker-compose.yml with user)
 ```yml
 ...
 user: "1001:1001"
 command: minio server /data
 ...
 ```
 - All openshift containers

Fixes minio#7773
harshavardhana added a commit to harshavardhana/minio that referenced this issue Jun 12, 2019
This allows MinIO containers to run properly without
expecting higher privileges in situations where following
restrictions on containers are used

 - docker run --user uid:gid
 - docker-compose up (with docker-compose.yml with user)
 ```yml
 ...
 user: "1001:1001"
 command: minio server /data
 ...
 ```
 - All openshift containers

Fixes minio#7773
harshavardhana added a commit that referenced this issue Jun 12, 2019
This allows MinIO containers to run properly without
expecting higher privileges in situations where following
restrictions on containers are used

 - docker run --user uid:gid
 - docker-compose up (with docker-compose.yml with user)
 ```yml
 ...
 user: "1001:1001"
 command: minio server /data
 ...
 ```
 - All openshift containers

Fixes #7773
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants