Casvt / Kapowarr

Kapowarr is a software to build and manage a comic book library, fitting in the *arr suite of software.
https://casvt.github.io/Kapowarr/
GNU General Public License v3.0
348 stars 12 forks source link

UID/GID support for container #144

Open halkeye opened 3 months ago

halkeye commented 3 months ago

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

docker run -it --rm mrcas/kapowarr:v1.0.0-beta-4 ls -ltr
total 20
-rwxrwx--- 1 root root  163 Jul 11  2023 requirements.txt
drwxrwx--- 2 root root 4096 Nov 29 14:12 temp_downloads
-rwxrwx--- 1 root root 1251 Dec 27 14:19 Kapowarr.py
drwxrwx--- 5 root root 4096 Dec 31 16:52 frontend
drwxrwx--- 5 root root 4096 Jan  3 17:03 backend
docker run -it -u 1026:100 --rm mrcas/kapowarr:v1.0.0-beta-4
python3: can't open file '/app/Kapowarr.py': [Errno 13] Permission denied

Expected behaviour

It runs :)

Eg: (I added a chmod 755 to the container)

docker run -it -u 1026:100 --rm halkeye
[2024-03-09 19:19:04][MainThread][INFO] Starting up Kapowarr
Traceback (most recent call last):
  File "/app/Kapowarr.py", line 52, in <module>
    Kapowarr()
  File "/app/Kapowarr.py", line 23, in Kapowarr
    set_db_location(folder_path(*__DATABASE_FILEPATH__))
  File "/app/backend/db.py", line 106, in set_db_location
    makedirs(dirname(db_file_location), exist_ok=True)
  File "/usr/local/lib/python3.8/os.py", line 223, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/app/db'
Casvt commented 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.

halkeye commented 3 months ago

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.

Casvt commented 3 months ago

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.

halkeye commented 3 months ago

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.

Keatingfish commented 1 month ago

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