Host users take ownership of existing home directories

[eriktate]

This PR updates CreateHomeDirectory such that it takes ownership of existing home directories and their contents. I originally thought we were already chowning the directory contents and we were just omitting the directory itself. However, I realized while implementing that this only happened for the files copied from skel so we'll need to figure out if this is something we want to move forward with or not

changelog: Allows host user creation to take ownership of existing home directories on behalf of the newly created user.

[espadolini]

Do we have to recursively chown the whole home directory tree rather than make just the directory owned, readable(?) and accessible by the user? What if there's something in there that's owned by root and is not supposed to be read by the user?

If we do this we should definitely at least check and see if the uid that owns the directory isn't a user that already exists in the system.

[espadolini]

Why is this necessary? Collecting a slice of unbounded size of paths doesn't feel great.

[eriktate]

It probably isn't 🤔 This was copied from the existing function that used to be in utils, but I don't see any reason to keep this behavior

[eriktate]

Do we have to recursively chown the whole home directory tree rather than make just the directory owned, readable(?) and accessible by the user? What if there's something in there that's owned by root and is not supposed to be read by the user?

If we do this we should definitely at least check and see if the uid that owns the directory isn't a user that already exists in the system.

I think it depends on the expected behavior here. As far as I understand, the primary usage would be in moving users over to teleport that were previously managed some other way. Which would benefit from taking ownership of everything since it's meant to be effectively the same user. @rosstimothy do you think it would be acceptable to only take ownership of the directory and not the contents?

Validating the UIDs are "safe" to overwrite is a great idea 👍

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[francesco-doyensec]

Hello team 👋
Adding my 2-bits about this new logic pattern. chown is very dangerous and it may lead to multiple privilege escalation opportunities in linux. Below some examples and questions on your plan:

• How does it protect against symlinks exploitation?
• How does it behave if the user mounted something in their home?
• The previous owner could backdoor the directory e.g. putting something in .bashrc, then it could be possible to exfiltrate everything
• The check on the possibility to overwrite the ownership does not consider the GID, which in some cases could be of a different primary group (not the default user group), meaning that the group will lose its access to the directory after the execution of Teleport's routine

These are just the first aspects I could think of, but the exploitability of automated chown routines is wide.
My suggestion would be either:

• Do not perform any action and ask the user to manage the remaining files from the zombie directory, then retry
• Make just a copy of it, then delete and inform the user about the new location

Just to conclude, even on Linux itself, if the $HOME exists, they just inform the user without doing anything tricky

[rosstimothy]

@eriktate can we close this in favor of #47524?

[eriktate]

Closing in favor of #47524