AUTOMATIC1111: Enable running as non root user.

[sethdmoore]

trafficstars

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

[AbdBarho]

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]

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]

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]

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]

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.