[ https://issues.apache.org/jira/browse/SPARK-43368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728206#comment-17728206 ]
Yikun Jiang commented on SPARK-43368: ------------------------------------- - The mainly issue in here is wider permissions on /etc/passwd, this bring some pontential security issue. - This is original related to [1][2] to resolve the OpenShift random UID case. - The DOI maintainer recommand to use libnss_wrapper to fake user rather than change /etc/passwd I will submit a PR soon. [1] https://github.com/apache-spark-on-k8s/spark/pull/404 [2] https://github.com/docker-library/official-images/pull/13089#issuecomment-1534706523 [3] https://github.com/docker-library/official-images/pull/13089#issuecomment-1561793792 [4] https://github.com/docker-library/postgres/pull/448 > Address DOI comments about /etc/passwd > -------------------------------------- > > Key: SPARK-43368 > URL: https://issues.apache.org/jira/browse/SPARK-43368 > Project: Spark > Issue Type: Sub-task > Components: Spark Docker > Affects Versions: 3.5.0 > Reporter: Yikun Jiang > Priority: Minor > > chgrp root /etc/passwd && chmod ug+rw /etc/passwd > Wider permissions on /etc/passwd is concerning. What use case is broken if > the running user id doesn't exist? > echo ... >> /etc/passwd > Having the entrypoint itself modify /etc/passwd is fragile. Are there > features that are broken if the user doesn't exist in /etc/passwd (like > PostgreSQL's initdb that refuses to run)? Minimally, this should probably use > useradd and usermod rather than hand editing. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org