Docker-alpine: Best way to add user?

[jmreicha]

I have a scenario where I would like to run a given process under a specific username but when I try to do something like adduser <name> I get a command: not found error. I see that Alpine has a useradd command but it is bombing also. Is there a way to create a user to use as a service acocunt with a blank password to get the Docker build to work? I guess this isn't specific to Alpine but I haven't been able to find a good workaround for this yet.

[andyshinn]

Can you supply an example Dockerfile or steps that include using useradd where it is not working as expected?

[jmreicha]

@andyshinn I pulled most of the unrelated stuff out but here is an example that is failing for me with /bin/sh: useradd: not found. I'm actually attempting to start Moxi with supervisor with the moxi user.

FROM gliderlabs/alpine:3.1

RUN apk --update add bash wget dpkg-dev

# Moxi - http://www.couchbase.com/downloads
RUN \
  useradd moxi && \
  cd /tmp && \
  wget -q http://packages.couchbase.com/releases/2.5.0/moxi-server_2.5.0_x86_64.deb && \
  dpkg -i moxi-server_2.5.0_x86_64.deb

# Start
CMD ["/opt/bin/moxi"]

[andyshinn]

So, two things here:

• There is a adduser that is handled by BusyBox. You are probably looking for adduser -S moxi.
• You are trying to install a Debian package on Alpine. This won't work! You need either a musl compatible binary or a way to compile from source.

[jmreicha]

@andyshinn okay thanks. Yeah I had a feeling this method wasn't going to work but I got stuck before I got to that point :)

It looks like adduser -S moxi works though so that is good to know. I'll just mark as closed because I was mostly interested in knowing how to add a user with no password.

[f3l1x]

adduser -D -u 1000 [username] works like a charm! Thank you.

[karser]

I was able to do that using

FROM busybox
ARG PUID
ARG PGID

RUN addgroup -g ${PGID} abc && \
    adduser -D -u ${PUID} -G abc abc

[ns-cweber]

How do you add a user that isn't locked? Apparently, I can use usermod -p '*' username, but ideally I wouldn't have to install a package to get usermod...

[fattybenji]

The -D option should do the trick, as the help says :

# adduser --help
BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.

Usage: adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

    -h DIR      Home directory
    -g GECOS    GECOS field
    -s SHELL    Login shell
    -G GRP      Group
    -S      Create a system user
    -D      Don't assign a password
    -H      Don't create home directory
    -u UID      User id
    -k SKEL     Skeleton directory (/etc/skel)

[ashenm]

Unfortunately doing so seems to disable the account (analogue of passwd -l) instead of simply leaving the account passwordless (analogue of passwd -u).

Which is troublesome when using the account for remote logins. For instance, the the use of a profile created utilising the -D flag for script purposes would result the following error

User alpine not allowed because account is locked

Any workaround except calling passwd -u after creation?

[maikell]

Is there already a solution in 2019 for this?

[AXington]

I think the original question has been answered... -D creates it without a password... as for the second question by ashenm: can you not do something like:

adduser foo << PASSWORD
password
password # for confirmation
PASSWORD

or redirect from a file adduser foo < password.txt

or pipe it in echo "password\npassword" | adduser foo?

or look at expect? I mean... really this is a sh question not an alpine-docker question... did you try googling it? because I just did, I've known about a couple of the hacks above, but didn't know about expect, and low and behold: https://stackoverflow.com/questions/14392525/passing-arguments-to-an-interactive-program-non-interactively

Either way, I'm not really sure that it's really a good ask... you really shouldn't be doing a remote ssh login on docker/kubernetes, it's a really insecure practice. kubectl exec -it is better.

[ashenm]

Hey @AXington, as of my understanding there's a difference between a disabled account and a passwordless account (simply put _an account with a blank password_), and my question revolves around that very difference.

As outlined in my previous comment, the use of flag -D while account creation seems to disable the created account instead of simply leaving the account passwordless which I find contrasting against the documentation;

    -D              Do not assign a password

While the above behaviour can be manipulated via numerous means to suit the desired outcome, the most straightforward being passwd -u after creation, I find it contradictory against the aforesaid documentation and silly to chain multiple subroutines when the sequel can be embedded into adduser itself.

Although the {docker,kubectl}\ exec is the generally preferred mechanism for command execution, a Dockerized SSH service serving numerous purposes such as tunneling is a clear exception and therefore I believe my question still stands relevant.

[AXington]

Either way, you're more likely to get a response from the developers if you ask the question in your own issue, rather than hijacking a 3 year old (now 4) closed issue where the OP's question was seemingly satisfied.

Also, you should be asking this of the right developers, not the people who put alpine on Docker. In this case, maybe busybox?

[ashenm]

It's already raised with BusyBox bearing reference 10981

[AXington]

I assume then that you've also tried their mailing list? https://busybox.net/FAQ.html#bugs

[ashenm]

@AXington thanks for drawing my attentions to the mailing list! I have now lodged the proceeding deets.