If you can’t run docker-compose without sudo, there’s something wrong with your setup. The specifics would be specific to your distro, but most likely there’s a user group you could add your user to with sudo gpasswd -a user group to make the docker run and docker-compose commands work without sudo. (Might have to log out and back in as well to make it take effect if you’ve ran that command during the current session.) To find the name of the group, you’ll probably have to do some research about your distro in particular. On Arch (insert hate here ;) ), I think the docker group does that, and it’s not unlikely that the equivalent group for your distro has the same name.

The “magical s” (called the “SUID bit”) shouldn’t be required to be able to run docker run and/or docker-compose without sudo. Theoretically if you did want to do that, you could do it with sudo chmod u+s /usr/bin/docker. But again it’s probably better to just add yourself to the proper group (or otherwise take the correct steps for your distro.)

But also, running docker-compose (or the docker run command more directly) without sudo won’t necessarily make things inside the docker container run as your user. Making it do so is a little complex, actually, but I’ll go through it here.

So, most Docker images that you’d get from Docker Hub or whatever usually run by default as root. If you do something like docker run -v /path/to/some/directory/on/your/host:/dir -it python 'touch /dir/foo', even if you’ve got your groups set up to be able to run docker run without sudo, it’ll create a file on your host named “foo” owned by root. Why? Because inside the container, the touch /dir/foo command ran as root.

Honestly, I’d be thrilled if Docker had ways to tell it to be smarter about that kind of thing. Something that could make Docker create the file on the host owned by your user rather than root even if inside the container, the command that creates the file runs under the user in the Docker container that is root/uid 1.

But that’s not how it works. If root inside the container creates the file, the host sees it as owned by root, which makes things a little more of a pain. C’est la vie.

Now, this is a bit of an aside, but it helped me understand so I’ll go ahead and include it. It seems impossible that a command run by your user (assuming you’ve got your groups set up correctly) shouldn’t be able to create a file owned by root, right? If without sudo you try to chown root:root some_file.txt, it’ll tell you permission denied. And it’s not the chown command that’s denying you permission. It’s the Linux kernel telling the chown command that that’s not allowed. So how can it be that the docker run command can create files owned by root when docker run wasn’t run by root, but rather by a more restricted user?

Docker has a daemon (called dockerd) that by default runs all the time as root, waiting for the docker command to direct it to do something. The docker run command doesn’t actually run the container. It talks to the daemon which is running as root and tells the daemon to start a container. Since it’s the daemon actually running the container and the daemon is running as root, commands inside the container are able to create files owned by root even if the docker run command is run by your own user.

If you’re wondering, yes this is a security concern. Consider a command like docker run -it -v /etc:/dir/etc alpine vi /dir/etc/sensitive/file. That command, theoretically, could for instance allow a non-root user to change the host’s root password.

How do you get around that? Well, there are ways to go about running the Docker daemon as a non-root user that I haven’t really looked into.

Another concern is if, for instance, you’ve got a web service running as root inside a Docker container with a bind volume to the host and the web app has, for instance, a shell injection vulnerability wherein a user could cause a command to run as root inside the docker container which could affect sensitive files outside. To mitigate that issue, you could either not bind mount to the host filesystem at all or run the web service in the Docker container as a different user.

And there are several ways to go about running a process in Docker as a non-root user.

First, some Docker images will already be configured to ensure that what is run inside the container runs as non-root. (When making a Docker image, you specify that by having a USER directive in the Dockerfile.) Usually if things are done that way, the user will also be present in the relevent files in /etc in the image. But as I mentioned earlier, that’s usually not the case for images on Docker Hub.

Next, if you’re using docker-compose, there’s a “user” option for setting the user.

Another way to do this is with the -u argument on the docker run command. Something like docker run -u 1000 -it alpine /bin/sh will give you a shell process owned by the user with id 1000.

Another way is to create the user and su to that user as part of the command passed to docker run. I’ve been known sometimes to do things like:

docker run \
	-it \
	alpine \
	sh -c 'adduser tootsweet ; su tootsweet -c /bin/sh'

The only other thing I can think to mention. Sometimes you want not just to run something in a Docker container not as root but in fact to run it as a user id that matches the user id of a particular user on the host. For instance so that files written to a bind volume end up being owned by the desired user so we can work with the files on the host. I honestly haven’t found the best way to deal with that. Mostly I’ve been dealing with that situation with the last method above. The useradd command allows you to add a user with a specific user id. But that’s problematic if the needed uid is already taken by a user in the container. So, so far I’ve kindof just been lucky on that score.

Hopefully that all helps!