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

useradd incorrectly modifies symbolic link target #933

Closed
stoeckmann opened this issue Jan 31, 2024 · 4 comments · Fixed by #969
Closed

useradd incorrectly modifies symbolic link target #933

stoeckmann opened this issue Jan 31, 2024 · 4 comments · Fixed by #969

Comments

@stoeckmann
Copy link
Contributor

The copy_symlink function in lib/copydir.c incorrectly adjusts symbolic link targets. I am not sure if these links should be modified at all.

How to reproduce:

ln -s /etc/skel2 /etc/skel/link
useradd -m user
ls -l /home/user

The output is lrwxrwxrwx 1 user user 11 Jan 31 21:02 link -> /home/user2.

This happens because the copy_symlink function just checks if the target of the link starts with /etc/skel which is the directory from where we are copying. If at all, it would have to check for /etc/skel/. This wouldn't work for link targets like ///etc/skel though or other variants.

Since someone created a symbolic link with an absolute path, I would argue it should stay absolute. It's the easiest fix.

edneville added a commit to edneville/shadow that referenced this issue Mar 12, 2024
edneville added a commit to edneville/shadow that referenced this issue Mar 12, 2024
@hallyn
Copy link
Member

hallyn commented Mar 13, 2024

Since someone created a symbolic link with an absolute path, I would argue it should stay absolute. It's the easiest fix.

This is what it's basically done forever. I don't think this is the kind of change we are at liberty to make.

@alejandro-colomar
Copy link
Collaborator

alejandro-colomar commented Mar 13, 2024

That makes sense, @hallyn .

If we don't accept #966 (@edneville), then I think my second favourite option would be to keep this obviously broken, so keep it as is.

I wouldn't like changing this to check for a trailing /, which would still be a breaking change, and would be behavior that isn't expected by anyone (except probably by who wrote that code in the first place).

I'll keep my approval in that PR, for historic reasons (and because I agree that's the behavior we'd want if adding the feature today). I guess we can close the PR, and eventually come back to it if we need to.

@edneville
Copy link
Contributor

@alejandro-colomar, if not accepted then perhaps this should be documented so that we don't get the same issue popping up. Does that seem a better approach, if so I can adjust the PR. The behaviour can be written in the man page, if needed instead.

@alejandro-colomar
Copy link
Collaborator

alejandro-colomar commented Mar 13, 2024

@alejandro-colomar, if not accepted then perhaps this should be documented so that we don't get the same issue popping up. Does that seem a better approach, if so I can adjust the PR. The behaviour can be written in the man page, if needed instead.

Sure, I think this issue should be documented, in a BUGS section (it's a known bug that we can't fix for reasons). But please don't change that PR. I'd like to keep it as is. Please open a new one.

edneville added a commit to edneville/shadow that referenced this issue Mar 14, 2024
Mention that symlinks are modified when they prefix the skel directory.

Closes shadow-maint#933
hallyn pushed a commit that referenced this issue Mar 14, 2024
Mention that symlinks are modified when they prefix the skel directory.

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

Successfully merging a pull request may close this issue.

4 participants