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 #2907

Closed
st3iny opened this issue Jun 10, 2022 · 8 comments
Closed

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

st3iny opened this issue Jun 10, 2022 · 8 comments

Comments

@st3iny
Copy link
Contributor

st3iny commented Jun 10, 2022

Trilium Version

0.52.2

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

Kubernetes

Description

There was a breaking change in #2864 that breaks Kubernetes setups which use a securityContext to change the uid. This also potentially breaks dockerfiles and docker-compose setups that try to change the uid.

The binary su-exec has to be run as root. Otherwise, there will be errors on execution like su-exec: setgroups: Operation not permitted and the app won't start.

I'm fine with this change but encourage you to add it to the release notes.

This is a common issue, e.g. minio/minio#7773

@st3iny st3iny changed the title Missing breaking change in release notes Use of su-exec now requires container be started as root Jun 10, 2022
@zadam
Copy link
Owner

zadam commented Jun 10, 2022

Hi, thanks for the heads-up.

TBH the Dockerfile situation is pretty frustrating, there have been some breaking changes in the past and every iteration seems to have problems.

@bill88t
Copy link
Contributor

bill88t commented Jun 11, 2022

Yea this isn't kubernetes-specific. My docker-compose which enforces uid & gid = 1000 broke too.
It just doesn't want to run without root.

@mikkel1156
Copy link

Looking through the minio issue I saw that they have a fallback for the su-exec command, which works for @st3iny since Kubernetes should take care of the permissions. But would probably also need a fallback for the chown in that case.

@st3iny
Copy link
Contributor Author

st3iny commented Jun 12, 2022

I prefer the current solution because it makes the image more self-contained and secure by default. In my opinion, using security contexts is more of a crutch to fix overprivileged containers/apps. I was also able to drop my init container that I added to fix the default permissions inside the persistent volume.

This change should just be communicated in a clear way because this change breaks some setups and requires manual intervention to fix. It is already documented in the release notes but it wouldn't hurt to amend the wiki as well (e.g. here and here).

@zadam
Copy link
Owner

zadam commented Jun 12, 2022

I added some details based on my limited understanding. Wiki is publicly editable, correcting/improving information is highly appreciated.

@st3iny
Copy link
Contributor Author

st3iny commented Jun 12, 2022

Wiki is publicly editable, correcting/improving information is highly appreciated.

Good to know! I amended the kubernetes page with some more information.

@cwilliams5
Copy link

TBH the Dockerfile situation is pretty frustrating, there have been some breaking changes in the past and every iteration seems to have problems.

Well then let me pass a thank you on, being able to maintain my own server to sync to is one of the things I adore about Trilium. Apologies that doing so has been so frustrating.

@st3iny
Copy link
Contributor Author

st3iny commented Jun 24, 2022

I'm closing this issue because it is documented well enough now.

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

5 participants