Don't clone dotfiles as root

[Julian]

Is your feature request related to a problem? Please describe

When dotfiles are cloned by gitpod, they're cloned as root.

This has surprising behavior, as it means files in ~ for the gitpod user will then be owned by root, a situation I think one would normally call broken home directory permissions.

In particular, if the user's dotfiles install script links or creates files (mine happens to do both), the system may end up being unusable without manually fixing permissions, as those files/directories will be owned by root once the workspace comes up.

(Obviously as in #19202 I'm aware I can workaround this as an end user -- just filing as the behavior seems quite surprising to me, so figured it'd be worth explicitly raising even if it's deemed expected or not a priority to fix).

Describe the behaviour you'd like

I'd personally consider running install scripts as the gitpod user -- but if that's somehow undesirable for other reasons, or because of backwards compatibility reasons, perhaps adding at least an option to specify which user to run the provisioning with is a stopgap. To me again though, that seems unneeded, as I should hope users who create install scripts for their own dotfiles aren't doing so assuming they'll execute the entirety of that script as root -- particularly users like me who are using that same script in environments other than Gitpod.

Describe alternatives you've considered

(The user option mentioned above)

Additional context

It seems this "issue" (if it isn't intended) is at least known -- e.g. I see a comment here asking or pointing out the same thing, and another here acknowledging this is the case.

[axonasif]

That sounds odd, I suspect it's because you have git submodules in your dotfiles repo, probably a bug.

Edit: Nope, it's something else, not because of git submodules. I can't reproduce with my own dotfiles 🤔

[Julian]

Huh, fascinating! Your dotfiles end up in a directory owned by gitpod?

[axonasif]

Yes.

[axonasif]

I saw that some files inside the .dotfiles dir was owned by gitpod and the rest was `root. Something in your files is probably causing this on Gitpod's dotfiles install logic. I tried your dotfiles by deleting the install scripts but it was still root, so it's probably something within the file structure or git metadata.

[Julian]

Only other thing that immediately occurs to me that may not be common in repos is having (git tracked) symlinks.

But I can also try to do some diagnosing later if helpful.

[andrewpatto]

I'm seeing this behaviour as well.. literally created a blank github repo - added a ./aws/config file to it (direct in github web UI - so no special file permissions or anything). When cloned across into a gitpod workspace the file get linked as root.

The corresponding ~/.aws folder is also then owned by root - which causes problems using any aws commands that expect write access.

[axonasif]

There might be a regression. But I'm still clueless why I'm unable to reproduce with my dotfiles (https://github.com/axonasif/dotsh). Maybe because I'm symlinking manually? But @Julian's dotfiles was symlinking manually as well.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.