Skip to content
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

Open
adrianriobo opened this issue Feb 20, 2023 · 3 comments
Open

[Bug] Handle permissions for output assets #45

adrianriobo opened this issue Feb 20, 2023 · 3 comments
Assignees

Comments

@adrianriobo
Copy link
Contributor

Currently create operation generate two types of assets:

  • pulumi related files; files for store the state of the infrastructure resources created by crc-cloud, and to control pulumi execution. The location for these assets is specified with the parameter backerd-url. And they are required to be passed to destroy 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 and password. The location for these files is specified with parametr output.

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.

@gbraad
Copy link
Contributor

gbraad commented Mar 3, 2023

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.

@lmilbaum
Copy link
Contributor

lmilbaum commented Mar 5, 2023

I actually wanted to ask if we could switch to ubi based images (drinking our own champion and all)

@praveenkumar
Copy link
Member

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.

$  docker run --rm -it -v ${PWD}:/workspace:z  --entrypoint=/bin/sh quay.io/crcont/crc-cloud:v0.0.2
/ # whoami
root
/ # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
/ # cd /workspace/
/workspace # touch hello
/workspace # chmod 0600 hello 
/workspace # exit

$ ls -l
total 12
-rw-------  1 prkumar prkumar   28 Mar 14 14:10 hello <= right user/group

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 0644 so that even rootful daemon can work.

<== start using docker socket with root ===>
$ docker run --rm -it -v ${PWD}:/workspace:z  --entrypoint=/bin/sh quay.io/crcont/crc-cloud:v0.0.2
/ # cd /workspace/
/workspace # ls
/workspace # touch hello
/workspace # cat hello 
adfadf
adfadfa
fadfaf
/workspace # exit

$ ls -l
total 4
-rw-r--r-- 1 root root 22 Mar 14 14:21 hello <== root user/group but permission 0644
$ cat hello
adfadf
adfadfa
fadfaf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

4 participants