I would like to create a directory using a bash script and then set the mode to 00755 at the same time
mkdir -p -m=00755 "/dir/dir2"
Is this the correct way of using them together and can I also add chown command to the same line while creating them?
It goes a little like this:
install -d -m 0755 -o someuser -g somegroup /dir/dir2
If you want to set the owner during creation, you can simply impersonate as this user, using sudo for example:
sudo -uTHE_USER mkdir -p -m=00755 "/dir/dir2"
This has the advantage that there will be no time difference between creation and changing the ownership, which could otherwise being harmful if exploited.
Yes that should work. As for the chown, simply follow the command ' && chown... '. && is similar to ; except the next command ONLY executes if the previous command exits success (0).
Related
I'm trying to create a new user with UID 1340816314 inside an Alpine Linux Docker container in order to have a user with an UID matching a specific user on the host.
The problem is that I'm facing adduser: number 1340816314 is not in 0..256000 range even if I redefine the value of UID_MAX inside /etc/login.defs by following adduser man page. I don't think by the way that it has any impact as the adduser command in Alpine is from BusyBox.
Here is the log of what I try to do:
$ docker run -it --rm alpine:3.4 sh
/ # adduser -D -g '' -u 1340816314 user
adduser: number 1340816314 is not in 0..256000 range
/ # echo "UID_MAX 1340816314" > /etc/login.defs
/ # adduser -D -g '' -u 1340816314 user
adduser: number 1340816314 is not in 0..256000 range
/ # echo "UID_MAX 1340816315" > /etc/login.defs
/ # adduser -D -g '' -u 1340816314 user
adduser: number 1340816314 is not in 0..256000 range
Do you know how to add a user with a large UID in Alpine Linux inside a Docker container?
There is a more elegant solution to the high UID/GID in Alpine.
The package shadow contains the useradd and groupadd utilities which in turn supports higher values. Not sure which is the upper bound of those utils and if the whole 2^32 space is supported, but I've tested with values over 600 million and it works.
For example the commands to achieve this would look something like this:
UID=666000666
GID=999000999
apk add shadow
/usr/sbin/groupadd -g ${GID} my_group
/usr/sbin/useradd -s /bin/sh -g ${GID} -u ${UID} my_user
Note that I'm passing the shell variable to useradd as by default it tries to use /bin/bash which is not installed.
Here is a working but dirty workaround, by manually creating the user, using $UID_TO_SET as the bash variable containing the high UID to set:
# Create user
echo "user:x:$UID_TO_SET:$UID_TO_SET::/home/user:" >> /etc/passwd
## thanks for http://stackoverflow.com/a/1094354/535203 to compute the creation date
echo "user:!:$(($(date +%s) / 60 / 60 / 24)):0:99999:7:::" >> /etc/shadow
echo "user:x:$UID_TO_SET:" >> /etc/group
mkdir /home/user && chown user: /home/user
This problem actually inspired me to solve it in a way, which is convenient and easy to use for this specific use case of getting long IDs to work on Alpine and BusyBox based Docker images.
https://github.com/theAkito/userdef
Example Usage:
## Get the binary.
## The default Docker Tag provides the Alpine (musl) based binary.
FROM akito13/userdef AS base
## Pull the image you want to modify the executing user of.
FROM gitea/gitea:1.16.5-linux-amd64-rootless
## We temporarily need to use the root user,
## as we are doing administrative tasks, like e.g. modifying an OS user.
USER root:root
COPY --from=base /userdef /userdef
## 1. Change the existing user.
## 2. Use that user to `chown` relevant folders.
## 3. Remove the binary, because the user has been changed,
## i.e. our job is done here.
RUN /userdef -h=/var/lib/gitea/git -n=git -u=9234 -g=9234 && \
chown git:git -R /var/lib/gitea /etc/gitea && \
rm -f /userdef
## Switch to the now relevant executing user.
USER 9234:9234
## Taken from https://github.com/go-gitea/gitea/blob/66f2210feca0b50d305a46a203c2b3d2f4d3790b/Dockerfile.rootless#L71-L72
ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]
CMD []
Elaboration on the only working answer from #anthony-o
# FOR UID higher than 60000, users need to be added like this!
RUN export GUID_TO_SET=100 && \
export UID_TO_SET=66666 && \
export USER=youruser && \
echo "${USER}:x:${UID_TO_SET}:${GUID_TO_SET}:Linux User,,,:/home/${USER}:/bin/sh" >> /etc/passwd && \
echo "${USER}:!:$(($(date +%s) / 60 / 60 / 24)):0:99999:7:::" >> /etc/shadow && \
mkdir /home/${USER} && \
chown ${USER}:${GUID_TO_SET} /home/${USER}
While the "dirty" methods above do work, they are ugly and not easy for some people to use. It would be easy to make a mistake with copy and paste.
So given that this is related to Docker, I've got a better way using multi-stage builds.
## Busybox adduser doesn't allow UIDs over 60000
## So we'll use a debian image to make the user
## And then copy the files and grep out the new user into the busybox container
FROM debian as base
RUN useradd -D -g '' -u 1340816314 user
FROM alpine as image
COPY --from=base /etc/passwd /root/passwd
RUN grep user /root/passwd >> /etc/passwd && rm -f /root/passwd
USER user
While this example uses debian, you can use any container image you want in the first stage instead of Debian. As long as the container doesn't error out because of an arbitrarily low UID limit in the command you use, it should be fine, so I encourage you to play around with different containers as the base image and also check if both useradd and adduser commands are available and which one might support the UID number you need.
I am using the docker-solr image with docker, and I need to mount a directory inside it which I achieve using the -v flag.
The problem is that the container needs to write to the directory that I have mounted into it, but doesn't appear to have the permissions to do so unless I do chmod 777 on the entire directory. I don't think setting the permission to allows all users to read and write to it is the solution, but just a temporary workaround.
Can anyone guide me in finding a more canonical solution?
Edit: I've been running docker without sudo because I added myself to the docker group. I just found that the problem is solved if I run docker with sudo, but I am curious if there are any other solutions.
More recently, after looking through some official docker repositories I've realized the more idiomatic way to solve these permission problems is using something called gosu in tandem with an entry point script. For example if we take an existing docker project, for example solr, the same one I was having trouble with earlier.
The dockerfile on Github very effectively builds the entire project, but does nothing to account for the permission problems.
So to overcome this, first I added the gosu setup to the dockerfile (if you implement this notice the version 1.4 is hardcoded. You can check for the latest releases here).
# grab gosu for easy step-down from root
RUN mkdir -p /home/solr \
&& gpg --keyserver pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
&& curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture)" \
&& curl -o /usr/local/bin/gosu.asc -SL "https://github.com/tianon/gosu/releases/download/1.4/gosu-$(dpkg --print-architecture).asc" \
&& gpg --verify /usr/local/bin/gosu.asc \
&& rm /usr/local/bin/gosu.asc \
&& chmod +x /usr/local/bin/gosu
Now we can use gosu, which is basically the exact same as su or sudo, but works much more nicely with docker. From the description for gosu:
This is a simple tool grown out of the simple fact that su and sudo have very strange and often annoying TTY and signal-forwarding behavior.
Now the other changes I made to the dockerfile were these adding these lines:
COPY solr_entrypoint.sh /sbin/entrypoint.sh
RUN chmod 755 /sbin/entrypoint.sh
ENTRYPOINT ["/sbin/entrypoint.sh"]
just to add my entrypoint file to the docker container.
and removing the line:
USER $SOLR_USER
So that by default you are the root user. (which is why we have gosu to step-down from root).
Now as for my own entrypoint file, I don't think it's written perfectly, but it did the job.
#!/bin/bash
set -e
export PS1="\w:\u docker-solr-> "
# step down from root when just running the default start command
case "$1" in
start)
chown -R solr /opt/solr/server/solr
exec gosu solr /opt/solr/bin/solr -f
;;
*)
exec $#
;;
esac
A docker run command takes the form:
docker run <flags> <image-name> <passed in arguments>
Basically the entrypoint says if I want to run solr as per usual we pass the argument start to the end of the command like this:
docker run <flags> <image-name> start
and otherwise run the commands you pass as root.
The start option first gives the solr user ownership of the directories and then runs the default command. This solves the ownership problem because unlike the dockerfile setup, which is a one time thing, the entry point runs every single time.
So now if I mount directories using the -d flag, before the entrypoint actually runs solr, it will chown the files inside of the docker container for you.
As for what this does to your files outside the container I've had mixed results because docker acts a little weird on OSX. For me, it didn't change the files outside of the container, but on another OS where docker plays more nicely with the filesystem, it might change your files outside, but I guess that's what you'll have to deal with if you want to mount files inside the container instead of just copying them in.
When I changed my current user to admin using
sudo su admin
I found that the environment variable changed too. What I intend to do is to change my user to admin with the env not changed.
Then I found a command as follows:
sudo bash -c "su - admin"
This command does indeed what I want, but I googled about bash -c, with no clue to why this command can do that for me. Could anyone give me a clear explanation? Thanks a lot.
first you should read the sudo manpage and set theses options in the /etc/sudoers file or you can do it interactively (see second below).
default sudoers file may not preserve the existing $USER environment unless you set the config options to do so. You'll want to read up on env_reset because depending on your OS distribution the sudo config will be different in most cases.
I dont mean to be terse but I am on a mobile device..
I do not recommend using sudo su .. for anything. whomever is sharing sudo su with the public is a newb, and you can accomplish the same cleaner with just sudo.
with your example whats happining is you are starting a subshell owned by the original user ("not admin") . you are starting the subshell with -c "string" sudo has the equivelant of the shell's -c using -s which either reads the shell from the arg passed to -s or the shell defined in the passwd file.
second you should use:
$ sudo -u admin -E -s
much cleaner right ? :)
-u sets the user, obviously
-s we just explained
-E preserves the orig user env
see for yourself just
$ echo $HOME # should show the original users /home/orig_user
$ env
your original env is preserved with none of that sudo su ugliness.
if you were interested in simulating a users login without preserving the env..
$ sudo -u user -i
or for root:
Might require -E depending on distro sudoers file
$ sudo -s
or
$ sudo -i
-i simulates the login and uses the users env.
hopefully this helps and someone will kindly format it to be more readable since im on my mobile.
bash with -c argument defines below.
-c string
If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0.
Thanks & Regards,
Alok
I'm trying to use multiple parameters with the useradd command in linux, and I'm not really sure exactly what I should do??
I have tried the following:
useradd -b /home/ -g admin -m -p PASSWD -s USERNAME
Needless to say, it doesn't work. Can anyone tell me the correct syntax to get this working? Thanks, your help is always appreciated!
EDIT: I'm not getting an error message, It is just returning the flag variables followed by an ng
The -s flag is for specifying the shell.
So either leave the -s flag out,
useradd -b /home/ -g admin -m USERNAME
or specify a shell:
useradd -b /home/ -g admin -m -s /bin/bash USERNAME
PS. Don't specify the password on the command line. It would be visible to other users listing the processes. Moreover, specifying the password this way requires you to enter the encrypted password.
hmmmm maybe the MAN page: useradd
Okay, I currently use an eggdrop IRC bot on my server. I want to make a bash script to start it up as well as a few other scripts at the same time. All that's left is to make it start, but it won't run as root.
However, I also need to be in the current directory of the file to run it, or it displays an error.
For example:
/home/eggdrop/eggdropbot/eggdrop will display an error, so to run it I need to
cd /home/eggdrop/eggdropbot and then ./eggdrop
So I can't just use "sudo -u eggdrop /home/eggdrop/eggdropbot/eggdrop" and as you probably know, sudo won't cd, either, since that would be pointless.
Any suggestions?
Why not just cd first and then sudo -u ./eggdrop .?
What about doing the cd, and, only then, launch the command with sudo ?
I suppose something like this should do the trick :
cd /home/eggdrop/eggdropbot && sudo -u eggdrop ./eggdrop
You can cd to the directory as the root user and then use sudo -u to invoke the program from the working directory.