[ https://issues.apache.org/jira/browse/HDDS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863528#comment-16863528 ]
Eric Yang commented on HDDS-1609: --------------------------------- [~elek] I only build Ozone in Centos 7. This is the output using pull request #958 for HDDS-1677, but it doesn't address the privilege escalation problem with hard coded uid. The files are still owned by test: {code:java} drwxrwxrwx. 2 eyang eyang 146 Jun 13 18:48 . drwxrwxr-x. 3 eyang eyang 95 Jun 13 18:47 .. -rw-rw-r--. 1 eyang eyang 1833184 Jun 13 18:48 docker-ozone-basic-scm.log -rw-r--r--. 1 test users 241608 Jun 13 18:48 log.html -rw-r--r--. 1 test users 230050 Jun 13 18:48 report.html -rw-r--r--. 1 test users 325078 Jun 13 18:48 robot-ozone-auditparser-om.xml -rw-r--r--. 1 test users 323935 Jun 13 18:48 robot-ozone-basic-scm.xml{code} The correct implementation would be: # Adding -u to docker compose files # Add runAsUser to k8s yaml # Remove hadoop user from Dockerfile # Change ADD --chown=root . /opt/hadoop in Dockerfile This would ensure the output is owned by the process owner. Do you see any problem with this approach? > Remove hard coded uid from Ozone docker image > --------------------------------------------- > > Key: HDDS-1609 > URL: https://issues.apache.org/jira/browse/HDDS-1609 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task > Reporter: Eric Yang > Priority: Major > Fix For: 0.5.0 > > Attachments: linux.txt, osx.txt > > > Hadoop-runner image is hard coded to [USER > hadoop|https://github.com/apache/hadoop/blob/docker-hadoop-runner-jdk11/Dockerfile#L45] > and user hadoop is hard coded to uid 1000. This arrangement complicates > development environment where host user is different uid from 1000. External > bind mount locations are written data as uid 1000. This can prevent > development environment from clean up test data. > Docker documentation stated that "The best way to prevent > privilege-escalation attacks from within a container is to configure your > container’s applications to run as unprivileged users." From Ozone > architecture point of view, there is no reason to run Ozone daemon to require > privileged user or hard coded user. > h3. Solution 1 > It would be best to support running docker container as host user to reduce > friction. User should be able to run: > {code} > docker run -u $(id -u):$(id -g) ... > {code} > or in docker-compose file: > {code} > user: "${UID}:${GID}" > {code} > By doing this, the user will be name less in docker container. Some commands > may warn that user does not have a name. This can be resolved by mounting > /etc/passwd or a file that looks like /etc/passwd that contain host user > entry. > h3. Solution 2 > Move the hard coded user to range < 200. The default linux profile reserves > service users < 200 to have umask that keep data private to service user or > group writable, if service shares group with other service users. Register > the service user with Linux vendors to ensure that there is a reserved uid > for Hadoop user or pick one that works for Hadoop. This is a longer route to > pursuit, and may not be fruitful. > h3. Solution 3 > Default the docker image to have sssd client installed. This will allow > docker image to see host level names by binding sssd socket. The instruction > for doing this is located at in [Hadoop website| > https://hadoop.apache.org/docs/r3.1.2/hadoop-yarn/hadoop-yarn-site/DockerContainers.html#User_Management_in_Docker_Container]. > The pre-requisites for this approach will require the host level system to > have sssd installed. For production system, there is a 99% chance that sssd > is installed. > We may want to support combined solution of 1 and 3 to be proper. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org