[ https://issues.apache.org/jira/browse/HDDS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861036#comment-16861036 ]
Elek, Marton commented on HDDS-1609: ------------------------------------ I don't think that the rpcuser is better than httpd. For me both of them are more confusing than hadoop user. But to be honest I am lost a little bit about the real problem. Can you please share a step by step guide to reproduce the problem (what should I execute, what is the current output, what is the expected output)? As far as I understood the only blocker problem right now is the way how the compose files are used in HDDS-1554. With using smoketest and store the data inside the containers all the problem would be solved. But I might miss something. Would be great to get a definition how the problem can be reproduced. > 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 > > 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