For those of you outside the U.S. who don’t know, Thanksgiving is basically a simultaneous celebration and revision of the genocide of the indigenous peoples of North America where people eat turkey and disgusting green bean slop.
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:
<span style="color:#323232;">docker run
</span><span style="color:#323232;"> -it
</span><span style="color:#323232;"> alpine
</span><span style="color:#323232;"> sh -c 'adduser tootsweet ; su tootsweet -c /bin/sh'
</span>
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!
Edit: P.S. apparently the way lemmy.world is set up, you can’t mention certain standard *nix file paths such as / e t c / p a s s w d in posts. The post just isn’t accepted. The “reply” button grays out and the loading graphic spins forever with no error message and the post doesn’t get saved. I’m sure this is a misguided attempt at a security measure, but it definitely affects our ability to communicate about standard Linux kind of stuff.
It returns that while you have nano running? If so, maybe try ps aux (without the grep part) and just look through until you find “nano” listed. Just to make sure whether it’s running as root or your non-root user.
(And just to be clear, “my sudoer username” means the non-root user that you’re running nano as, right?)
Just a gut feeling, but it feels to me so far like this probably isn’t a hack or security thing. But of course, once the (no pun intended) root issue is found, that’ll provide more info.
Maybe try alias nano and LC_ALL=C type nano. Those test whether you have an alias or function named “nano” in bash that might be being run instead of /usr/bin/nano.
Oh, also, whoami and id. Maybe there’s something weird with how you’re logged in and despite not having the username “root” you’re still uid 1 or something strange like that?
Oh! Also maybe while you’ve got nano running, do a ps aux | grep nano and see which user is reported to own that process.
Try an ls -l $(which nano) and look at the permissions section of the output.
Most files only have hyphens, r’s, w’s, and x’s. (Like -rwxr-xr-x or some such.)
Particularly if there’s an “s” in the output (it’ll be in place of an “x”), that could explain what’s going on.
Basically, that “s” means “when a user runs me, run me as root even if the user running me isn’t root.” It’s useful on programs like “su” and “sudo” which let you run a command that (after authentication) do things as root.
But if that flag is set on nano, that’s pretty weird.
They’re not worried about individuals like ourselves making our own private modifications if we so care to.
Apparently they are, because they don’t allow it in their license and the way the license is written makes its absence seem rather conspicuous and intentional.
If they do eventually make good on their promise (from “pledge #3”) to make it Open Source, then maybe I’ll be interested. Until then, I’m not taking the word of a random Lemmy user what they are “worried about individuals like ourselves” doing. I’m taking their own (legal department’s) word.
they just expect the few that do happen to go out of their way to modify their apps don’t distribute their mods without authorization.
The main infrastructure of their license is to make sure the big companies out there can’t legally rip off their code, alter it and sell it under their own branding or such.
You have to understand that every piece of FOSS software out there allows anyone to “legally rip off their code, alter it and sell it under their own branding or such.” Any piece of software out there that doesn’t allow that does not qualify as Open Source or Free Software.
(It rustles my jimmies to use the term “rip off” in this context, but I hoped quoting your exact words directly would make it clearer)
If Grayjay’s license doesn’t allow that and if they see doing that as “ripping off”, then I have no interest in supporting or using that software unless/until that changes.
When I say “I won’t use it unless it’s FOSS,” I mean among other things that I won’t use it unless its license allows anyone to redistribute it and/or any derivative works of it either for profit or not and under a different brand. That’s how FOSS works.
(Ok. One caveat to the above that applies to some FOSS licenses (but probably not all.) I believe if someone violates the terms of, for instance, the GPL, then the permission to continue redistributing is revoked until they’re back in compliance with the terms of the license.)