[
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
