[Issue]: Docker defaults running jellyfin process as root

[jNullj]

Please describe your bug

The jellyfin process runs as root in the docker container.
I don't have much experience but i suspect it to be bad practice, for example official mysql image for docker is checking if the container is running as root, if so it runs the process as the mysql user created at image creation. (link to entry point script)
I belive this increases security.

Jellyfin Version

10.7.7

if other:

No response

Environment

- OS: Arch
- Virtualization: Docker
- Clients: Browser

Jellyfin logs

No response

FFmpeg logs

No response

Please attach any browser or client logs here

No response

Please attach any screenshots here

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jNullj]

still issue still affects me, i looked at the dockerfile on master and i dont see any trace of a solution.

[jNullj]

still issue still affects me, i looked at the dockerfile on master and i dont see any trace of a solution.

[jNullj]

still issue still affects me, i looked at the dockerfile on master and i dont see any trace of a solution.

[Shadowghost]

Feel free to post a PR fixing the issue in a way you seem fit.

[mpeter50]

Can we please mark this issue with a tag that will exclude it from automatically closing it? This is not a problem that will go away without someone closing it with reason.
The 'confirmed' and 'future' tags also seem appropriate.

[mpeter50]

Can we please mark this issue with a tag that will exclude it from being closed automatically?
The problem is still relevant, it will not go away without someone closing it with a solution.

The 'confirmed' and 'future' tags also seem appropriate.

[joshuaboniface]

I agree with the idea here, but am not sure about the actual implementation or how it will affect e.g. existing containers.

I know at some point in the past this was tried and didn't work, but I don't know the details of what was done or why it failed. Probably HWA related and additional setup.

I'd definitely welcome PRs to address this.

[thornbill]

I'm not entirely convinced we should add any custom handling for this... running containers as root is the default in the docker ecosystem (for better or worse) but it can be provided a user or user id to run as a different user.

https://stackoverflow.com/questions/35734474/connect-to-docker-container-as-user-other-than-root#35736699

[mpeter50]

but am not sure about the actual implementation or how it will affect e.g. existing containers

An option could be to have this as a new container "flavor", like 10.9-rootless or something like that.
If it works right, it could become the default one over time, but maybe that is not a good idea dependeng on the changes needed.

Probably HWA related

If we can't solve that, maybe we can still have a rootless container, but with very visible signs (e.g. in the dockerhub readme, maybe also with a log line when the container is starting up) that you wont be able to use hardware acceleration (for now) with that image.

[jNullj]

We might be able to get inspiration from photoprism
link to doc about rootless container and hwa

Can't users add permission for the user running jellyfin to the hwa device?

[joshuaboniface]

Can't users add permission for the user running jellyfin to the hwa device?

Theoretically, yes. But HWA is already a bit of a troubleshooting nightmare and adding yet another variable into the equation is not something we're really keen on.

There is documentation on how to run the existing container image as a non-root user for both Docker Compose and Podman, but the default container using default docker is still root.

[ferferga]

I solved this problem in Vue this way a few weeks ago, but only for opening ports, there might be a need for extra capabilities in the server's case: https://github.com/jellyfin/jellyfin-vue/blob/master/packaging/docker/contents/postunpack.sh#L18

In case it's useful for someone to open a PR in the meantime, if not I will open it at some point since it's something I'd like to improve in the current packaging process regardless (but it can take a lot of time until I tackle it, hence why a PR is good regardless).