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

AUTOMATIC1111: Enable running as non root user. #546

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

sethdmoore
Copy link

Expose build args to container which allow the web service to run as given uid:gid.

Recent commits have broken my SD model NFS share, so I've decided to try and fix the problem.
Not sure if anyone else wants these changes, but here they are. They are tested and working to the best
of my ability.

By default, this behavior is "off". Building via docker compose still defaults to root:root on everything. Unless these args are explicitly set, no users should notice a difference.

Build arguments are also exposed as Docker environment variables, so they can be freely referenced in the entrypoint.sh

Output files will be owned by PUID and PGID, so if set, no more root:root images (unless desired).

New arguments:

  • ARG PUID=0
  • ARG PGID=0
  • ARG USER_HOME=/root

New environment variable:

  • RSYNC_FLAGS
    • NFS share doesn't like -a changing every directory bit

Example docker-compose.override.yaml using these flags

version: '3.9'

services:
  auto:
    environment:
      RSYNC_FLAGS: -vrlgotO
    build:
      args:
        USER_HOME: /opt/stablediffusion
        PUID: 1000
        PGID: 1002
    volumes:
      - /media/data:/data
      - /tmp:/output
  download:
    volumes:
      - /media/data:/data

Expose build args to container which allow the web service
to run as given uid:gid.

By default, this behavior is "off". Building via docker compose still
defaults to root:root on everything. Unless these args are explicitly
set, no users should notice a difference.

Build arguments are also exposed as Docker environment variables, so they can
be freely referenced in the `entrypoint.sh`

Output files will be owned by PUID and PGID, so if set, no more root:root
images (unless desired).

New arguments:
  - ARG PUID=0
  - ARG PGID=0
  - ARG USER_HOME=/root

New environment variable:
  - RSYNC_FLAGS
    - NFS share doesn't like `-a` changing every bit on a directory

Example docker-compose.override.yaml using these flags

```
version: '3.9'

services:
  auto:
    environment:
      RSYNC_FLAGS: -vrlgotO
    build:
      args:
        USER_HOME: /opt/stablediffusion
        PUID: 1000
        PGID: 1002
    volumes:
      - /media/data:/data
      - /tmp:/output
  download:
    volumes:
      - /media/data:/data
```
@AbdBarho
Copy link
Owner

Thanks, does this work on windows?
Also, when the container is running as non-root, would still be possible to install apt-dependencies that might be requires by some extensions?

@sethdmoore
Copy link
Author

sethdmoore commented Jul 26, 2023

Hey, thanks for getting back to me. I'm fairly sure it will work fine on Windows, but I can't say for sure. I don't have a non-virtualized Windows installation handy to test currently. Docker is implemented in a VM on Windows (and mac) anyhow, so I don't see why it would care about unix permissions.

Also yes, it is easy to execute things as root in a running with docker exec.

EG:

docker exec -it \
    --user root \
    stablediffusion \
    apt install -y foo bar baz

Of course, this would have no persistence (which I believe is the same case now), so some key directories might need to be added as volumes or someone would have to use this image as a base to install their desired extra packages.

@hazrpg
Copy link

hazrpg commented Jul 28, 2023

Awesome, this works for me! This has bugged me for a while and was just about to try and work on this myself.

Great work!

@AbdBarho
Copy link
Owner

AbdBarho commented Aug 26, 2023

Sorry for coming back late to this one.

Regarding this:

Of course, this would have no persistence (which I believe is the same case now), so some key directories might need to be added as volumes or someone would have to use this image as a base to install their desired extra packages.

Currently, we achieve "persistence" by using a startup.sh script to install / update packages, which runs (unsurprisingly) when the container starts, but before running the actual UI.

Is is possible to use the non-root container in a way that is compatible with this solution? what other alternatives we have?

@sethdmoore
Copy link
Author

Sorry for coming back late to this one.

Regarding this:

Of course, this would have no persistence (which I believe is the same case now), so some key directories might need to be added as volumes or someone would have to use this image as a base to install their desired extra packages.

Currently, we achieve "persistence" by using a startup.sh script to install / update packages, which runs (unsurprisingly) when the container starts, but before running the actual UI.

Is is possible to use the non-root container in a way that is compatible with this solution? what other alternatives we have?

Hello again,

So I'm not sure if there's an elegant solution involving non-root containers and installing packages at runtime.

Several options exist (adding sudo maybe?), but I think the most reasonable solution might be adding an extra build argument to install user specified debs.

Since a user would have to specify non-root build args anyway to build this container as unprivileged, I would suggest we add something like ARG EXTRA_PACKAGES and add a RUN step that installs said EXTRA_PACKAGES before dropping privileges.

I'm not sure how often people add or remove packages to their containers, but this seems like an okay workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants