Set 0444 as default secret mode in stack deploy #31006
Conversation
|
LGTM (nam) |
cli/compose/convert/service.go
Outdated
| @@ -217,13 +217,17 @@ func convertServiceSecrets( | |||
| if gid == "" { | |||
| gid = "0" | |||
| } | |||
| mode := secret.Mode | |||
| if mode == 0 { | |||
There was a problem hiding this comment.
Is this the right check? Mode 0 should be settable since it exists as a mode. If I tried to set the mode to 0 I'd be surprised if it ended up 444.
There was a problem hiding this comment.
I agree with @mstanleyjones .
Probably the type of Mode needs to be *uint32 rather than uint32
https://github.com/docker/docker/blob/60c1eaf8f08f904248cbfa0d07d850025a35e6d0/cli/compose/types/types.go#L232
There was a problem hiding this comment.
@mstanleyjones @AkihiroSuda yeah.. didn't thought of that, but yeah should probably be a pointer instead.
There was a problem hiding this comment.
Just curious, is there a situation one would want mode 0 for? It would not be readable or writeable by any user including root so to me that would be kind of like setting --name for a container to an empty string.
There was a problem hiding this comment.
I can't think of a situation where it would be useful, but it's a valid mode, so I feel we shouldn't overload it.
There was a problem hiding this comment.
@vdemeester do you have another way to do this that doesn't actively prevent the user from setting mode 0 on purpose? Principle of least surprise?
|
👍 |
Change the default secret mode to match the default one used in `service` subcommands. Signed-off-by: Vincent Demeester <vincent@sbr.pm>
vdemeester
force-pushed
the
30991-secret-mode-in-stack-deploy
branch
from
98e5689
to
f2b68c6
Compare
…ack-deploy Set 0444 as default secret mode in stack deploy (cherry picked from commit a12454d) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Change the default secret mode to match the default one used in
servicesubcommands.Fix #30991
/cc @dnephin @mstanleyjones @nathanleclaire @aaronlehmann @ehazlett @thaJeztah
🐸
Signed-off-by: Vincent Demeester vincent@sbr.pm