Add support for --chown <uid>:<gid> #125
Conversation
- Use these options when a whole directory hierarchy needs to be processed. - Extracted file processing logic in an extra process.go Partial solution to hairyhenderson#117
Don't know whether I touched this, but this test still repots an error. but with rc 1 instead of 2. Don't know if this ok. Please review whether this is my fauls or whether this ok like this.
No error returned anymore, direct panic instead.
If not given, the default is the current working directory Relates to PR hairyhenderson#119
Cant be used as a default to the CLI because it messes up the validation checks otherwise
… success Thanks to the awesome IT suite for triggering this Relates to hairyhenderson#119
Reverting according to review hairyhenderson#119 (comment)
The parameter can be given in the form <uid>:<gid> but also username and group names are supported _if_ the os supports the lookup. The safest way is to use numeric user ids. The use case for this feature is when the processed templates are expected to belong to a certain user/group. E.g. Wildfly Docker images, a prominent Java EE application server write into the configuration files, too but runs with a non-root uid and so needs the proper access. Depending on the uid under which the server run and the files has been created, this has to be tuned. Especially in a Docker context this might be helpful since Docker does not support changing the ownership with ADD or COPY (its always added as root). In order to avoid some postprocessing of the generated files (which might even not be possible e.g. when running from a scratch image without any installed shell), this options proves to be quite useful and add some flexibility (on the cost of an additional feature, though).
rhuss
changed the title
|
Thanks again, @rhuss! Wouldn't it work to just run In a non-Docker context, it should work to instead just set the uid/gid to the same as the input file (assuming the input belongs to a different user, and assuming the I'm thinking this option is straying a little too far outside the scope of what I want |
|
Right, it's about a Docker context, right, where you don't always have influence on the user which executes your container. But you are probably right, it's add too much complexity for little value (especially because this feature is also OS dependent and would need to be tested cross platform). |
|
👍 |
|
@hairyhenderson btw, wonder whether original file permission shouldn't be respected or whether it always ok to have 0644 on the files created as it is done here I think this could be easily fixed. |
|
@rhuss definitely I'd like original file permissions to be respected. Originally |
The parameter can be given in the form : but also username and
group names are supported if the os supports the lookup.
The safest way is to use numeric user ids.
The use case for this feature is when the processed templates are expected
to belong to a certain user/group. E.g. Wildfly Docker images, a prominent Java
EE application server write into the configuration files, too but runs with a non-root uid
and so needs the proper access. Depending on the uid under which the server
run and the files has been created, this has to be tuned.
Especially in a Docker context this might be helpful since Docker does not
support changing the ownership with ADD or COPY (its always added as root).
In order to avoid some postprocessing of the generated files (which might even
not be possible e.g. when running from a scratch image without any installed
shell), this options proves to be quite useful and add some flexibility
(on the cost of an additional feature, though).
This PR is based on #119 and add the commit rhuss@75a28b1