Open halkeye opened 3 months ago
We already had an attempt at this in a seperate branch but that didn't work for users on certain OS'es. I'm pretty sure your one liner won't cut it either for a good part of the users.
I don't have a GH action for building docker images because I want manual control over when it happens. The script that I use also does some extra stuff around the building of the images.
However, maybe together we can make it work for everyone. IIRC, our attempt worked well for Linux, MacOS and similar OS'es. I can't remember how it did on Windows. And it would crash on special ones like for those pre built NAS OS'es.
Thats not quite the problem I'm having. That tries to allow PGID/PUID (which are usually runtime env varibles) in compile time docker land.
All i'm doing is removing the restriction that is -->has<-- to be run as root, but allowing non uid 0 to execute /app
https://github.com/halkeye/kapowarr/blob/main/Dockerfile works just fine as root and non root
rwxrwx---
is only allow uid (0) and gid (0) to read/write/execute the files, other (the last 3) can't read or execute even
To reproduce what you have you could do 775 but 755 is usually the standard so only the file owner can write to it.
I still think you're describing the same problem. You want to run the container with a different user so that the downloaded files are also owned by that user instead of the root user. And you make sure that the container only has access to what you want by running it with a different user than root.
That's exactly what UID/GID support is for. It will run the application using the given user; isn't that exactly what you want?
All i'm doing is removing the restriction that is -->has<-- to be run as root, ~but~ by allowing non uid 0 to execute /app
I interpret this as you wanting to run the application using >0 UID. So we need to add support for setting the user that will run the application.
That's exactly what UID/GID support is for. It will run the application using the given user; isn't that exactly what you want?
I don't need a user to be created, docker lets you set the uid and gid via -u, really the only reason for pid/gid env variables that people use is to do setup, and then switch to non root. I don't want the container to ever have root access, so it doesn't need to su (via gosu or su or whatever else)
By setting the filesystem properly so "other" (as in non file owner) can read/execute the binary, its still essentially a read only container, but non root user can run the software.
It won't cause an issue with unraid and all the others, because its not messing with uid/gid at all, inside or outside the container, its just removing the root restriction.
I interpret this as you wanting to run the application using >0 UID. So we need to add support for setting the user that will run the application.
I don't want or need it. Docker can handle it, I don't need the binary to handle it.
see https://github.com/Casvt/Kapowarr/pull/145/files
all it needs is a single chmod to allow any other uid to run the application. By default it'll still be root, and still have the same behavior, but won't lock out non root.
I would say this. Currently I have to manually do new perms on every new folder that Kapowarr creates for a volume if I want to manually move a file into it, and I have the docker set to 99/100 for perms so something isn't allowing it to be open by default to outside root
Description of the bug
I like running my images as non root so in the case of downloaders, they have the right uid and gid for the downloaders/dbs. But also generally to prevent a container from having root access to the outerside filesystem.
When I try to do it for kapowarr i get permission denied
To Reproduce
Expected behaviour
It runs :)
Eg: (I added a chmod 755 to the container)