-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Handle permissions for output assets #45
Comments
This is a known issue how Docker handles a container; since an ubuntu image is used, and most likely runs as privileged, you will have 'root' owning teh assets. either use a specific UID/GID, or consider a custom image that run podman that handles this in a more graceful manner. |
I actually wanted to ask if we could switch to ubi based images (drinking our own champion and all) |
So this is what I tried and looks like the way podman maps the uid/guild for rootless is not achieved by docker (without rootless so I followed https://docs.docker.com/engine/security/rootless/ and then running same steps doesn't have permission issue.
Now there is also https://github.com/marketplace/actions/rootless-docker action which we use for the CI and in the document we mention it is tested using rootless docker/podman. Also in the meeting we discussed using the bit open file permission like
|
Currently
create
operation generate two types of assets:pulumi
related files; files for store the state of the infrastructure resources created bycrc-cloud
, and to controlpulumi
execution. The location for these assets is specified with the parameterbackerd-url
. And they are required to be passed todestroy
operation to let pulumi know about the resources to be destroyed.instance
access files;create
operation will output several files to inform data required to connected to created instance:host
,username
,id_rsa
andpassword
. The location for these files is specified with parametroutput
.The default execution mode for
crc-cloud
is based on a container, and typically the locations are set as mount path volumes. As depending on the tool / engine execution user for the container may change it could create issues with permissions on created files.As an example if you run container with
docker
it will use user container to set permissions and then files can not be accessed from the host.The text was updated successfully, but these errors were encountered: