[
https://issues.apache.org/jira/browse/KNOX-3257?focusedWorklogId=1006383&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1006383
]
ASF GitHub Bot logged work on KNOX-3257:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Feb/26 14:28
Start Date: 20/Feb/26 14:28
Worklog Time Spent: 10m
Work Description: moresandeep commented on PR #1151:
URL: https://github.com/apache/knox/pull/1151#issuecomment-3935199636
> The use of a fixed GID and group-based access makes sense for
Helm/Kubernetes compatibility.
>
> However, granting `g+rwx` on all directories under `home/knox` may be
broader than necessary.
>
> Since the JIRA mentions keystore updates specifically, would it be safer
to restrict write permissions to the directories that actually need mutation
(e.g., `data/security/keystores`, possibly `conf`)?
>
> This would better follow the principle of least privilege while preserving
the intended functionality.
Good point, the issue is that we need to move other resources as well e.g.
gateway-site.xml, there could be additional binaries that needs moving, then
there is also the init scripts for gateway and LDAP.
Specifically, the problem with k8s installations are
The path `/home/knox/knox/data/security/keystores/truststore.jks` requires
execute permission on every parent directory:
`/home/knox` = needs `g+x`
`/home/knox/knox` = needs g+x
`/home/knox/knox/data` = needs g+x
`/home/knox/knox/data/security` = needs g+x (from fsGroup + emptyDir)
`/home/knox/knox/data/security/keystores` = needs g+x
If any of these lack g+x, the entire path becomes inaccessible
Now, just making `data/security/keystores`, possibly `conf writable the
issues i ran into is
```
# Even if security/ is 777
$ ls -ld /home/knox/knox/data/security
drwxrwxrwx 2 8000 8000 ... security
# If parent data/ is 750 (no group execute)
$ ls -ld /home/knox/knox/data
drwxr-x-
Issue Time Tracking
-------------------
Worklog Id: (was: 1006383)
Time Spent: 50m (was: 40m)
> Update knox image creatation so that we do not need escalated privileges in
> helm install
> ------------------------------------------------------------------------------------------
>
> Key: KNOX-3257
> URL: https://issues.apache.org/jira/browse/KNOX-3257
> Project: Apache Knox
> Issue Type: Bug
> Components: docker
> Reporter: Sandeep More
> Assignee: Sandeep More
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently knox docker images are created such that only knox user has access
> to it's fil;es and directories. There are times when helm operations want to
> update the keystore, to add certs specifically, such operations need root
> privileges in helm (or use the exact knox UID which cannot be determined by
> helm container init). The proposed solution is to create a group "knox" with
> a specific GID and have all the knox specific dirs owned by this group.
> Then in helm we use that GID to perform operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
