Dockerfile*: default non-privileged user

[fgimenez]

Dockerfile*: default non-provileged user

Creates a geth user and group (1000:1000) and defaults to it for regular and alltools images. Also updated suggested docker command in README to mount volume in the non-privileged user home.

Closes: #15816

[GitCop]

Thank you for your contribution! Your commits seem to not adhere to the repository coding standards

• Commit: 13b269fb290a7a56b378fd4d5cae9577d42031fb
• Commits must be prefixed with the package(s) they modify

Please check the contribution guidelines for more details.

---

This message was auto-generated by https://gitcop.com

[karalabe]

What would the benefit of this change be?

A significant drawback is that this changes implicit APIs about the datadir location. E.g. any script mounting /root/.ethereum to external folders will immediately and silently break. For example, all private networks managed by puppeth.

[GitCop]

Thank you for your contribution! Your commits seem to not adhere to the repository coding standards

• Commit: 21ec2cdb3d6e14f171fc969bdeeb264377c0338f
• Commits must be prefixed with the package(s) they modify

Please check the contribution guidelines for more details.

---

This message was auto-generated by https://gitcop.com

[fgimenez]

Hey @karalabe thx for your comments :)

The main benefit is increased security, running a container's process as root is similar to running any other host process as root. It lets you do things like this:

fgimenez@dunwich:~$ sudo -s
root@dunwich:# echo "my very secret password" > /root/secret.txt
root@dunwich:# chmod 0600 /root/secret.txt 
root@dunwich:# exit
exit
fgimenez@dunwich:~$ cat /root/secret.txt
cat: /root/secret.txt: Permission denied
fgimenez@dunwich:~$ docker run --entrypoint /bin/cat -v /root:/root ethereum/client-go /root/secret.txt
my very secret password

A compromised container with its process running as root can potentially be very harmful. If the geth process doesn't require root IMO it would be good if it can run with the least privileges possible. I've pushed changes to overcome the issue you mentioned, changing the ownership of /root to geth:geth, let me know WDYT. Are there any other known tools that assume root?

[karalabe]

Your fix doesn't help the issue. Currently the internally running geth process uses /root/.ethereum as the data directory. If you change the username, the default datadir location changes too. Any tool wanting to map the internal geth's datadir to an outside folder will break.

[fgimenez]

Aha, I've pushed changes to set geth's home to /root, just checked and with the default entrypoint the data directory is created at /root/.ethereum as you pointed out, PTAL.

[ekryski]

I'd love to see this land. 😄

What would the benefit of this change be?

This is a Docker best practice for the exact reason that @fgimenez wrote. There are ways that you can get access to the host machine as well when the container is run as root.

[jeanlucmongrain]

Fatal: Failed to create the protocol stack: mkdir /root/.ethereum: permission denied

Who decided to map /root to a non-uid 0 user don't know what he's doing and ignore the basics of Linux.
And who merged that don't know either.

Why break the standard? What benefit it bring? NONE!

https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

Say that

3.14. /root : Home directory for the root user
(optional)
3.14.1. Purpose
The root account's home directory may be determined by developer or local preference, but this is the recommended default location.

An existing SYSTEM DIRECTORY used for an other purpose?

/var/lib/geth make sense, daemons use /var/lib/ to store data, like PostgreSQL Official Dockerfile and MySQL Official Dockerfile. geth is a daemon, even if it's often used by users on desktop system and data is stored in their equivalent of $HOME that doesn't mean it's not a daemon.
/home/geth for those who respect Linux but ignore the standard
/data could have been used, at some extend... because docker... it's used by Redis Official Docker and make 1000 times more sense than /root

/root terrible choice, this is not a bug it's a self inflicted wound

[fgimenez]

Apologies for the ill-defined PR.

[karalabe]

I tried to tell people this whole PR is a bad idea. Apparently running with custom users is more important than preserving APIs.

[jeanlucmongrain]

Because of this I'm stuck with 1.8.3

[karalabe]

I also don't get the thing with user and group 1000. What happens if user 1000 is a plain user and not even my user?

[karalabe]

I've reverted this PR (along with the rest of the cascading changes caused by it) and pushed a new release https://github.com/ethereum/go-ethereum/releases/tag/v1.8.6.

@fgimenez I'm sorry I had to revert, but the fallout was too large. I really appreciate the attempt, but we need to figure out a better was that doesn't go belly up on every user of the docker images.

[fgimenez]

@karalabe np at all, my fault. Tests worked fine, I wish I could have caught the issue earlier. Anyway, lesson learned.