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

Remove block preventing us from making hardlinks to symlinks #1187

Merged

Conversation

katiewasnothere
Copy link
Contributor

Addresses #1120. This PR removes the previous block preventing hardlinks from being made to symlinks. Since symlinks are evaluated dynamically in the container based on the current root and tar2ext4 bounds hard link targets within the root of the inode structure, we don't need additional checking of any symlink targets in this scenario.

Additionally adds test to verify behavior.

Signed-off-by: Kathryn Baldauf kabaldau@microsoft.com

@dcantah
Copy link
Contributor

dcantah commented Oct 5, 2021

Did we verify any of the troublesome images that were erroring here now work (and nothing wonky in the guest for the link)?

@katiewasnothere
Copy link
Contributor Author

Did we verify any of the troublesome images that were erroring here now work (and nothing wonky in the guest for the link)?

I didn't check with any specific container images. I did check with test tar files and the test included in the PR validate the PR. With the test tar files I made I validated that there was not break out.

@dcantah
Copy link
Contributor

dcantah commented Oct 5, 2021

Sure, just wanted to see if we've tried a container image that failed with the old behavior to be safe

@dcantah dcantah self-assigned this Oct 5, 2021
Copy link
Contributor

@dcantah dcantah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we should put an image that has a hardlink -> symlink in one of its layers up on our cplatpublic registry and make a cri-containerd test to be safe. Changes here lgtm though.

@katiewasnothere
Copy link
Contributor Author

I still think we should put an image that has a hardlink -> symlink in one of its layers up on our cplatpublic registry and make a cri-containerd test to be safe. Changes here lgtm though.

We discussed this and agreed that a test like this would be best suited for a different PR where we can include other extensive tests of the tar functionality.

@@ -620,8 +620,8 @@ func (w *Writer) Link(oldname, newname string) error {
return err
}
switch oldfile.Mode & format.TypeMask {
case format.S_IFDIR, format.S_IFLNK:
return fmt.Errorf("%s: link target cannot be a directory or symlink: %s", newname, oldname)
case format.S_IFDIR:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So with this change we are setting our policy as "hard links to symlinks will point to symlink itself than the file which symlink points to". Do we know if containerd upstream also follows the same policy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ambarve ambarve Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. Thanks!

Can we add a comment here saying that we follow containerd upstream policy and provide this link? It would help in the future.

Copy link
Contributor

@ambarve ambarve left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comment but LGTM!

Signed-off-by: Kathryn Baldauf <kabaldau@microsoft.com>
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 this pull request may close these issues.

None yet

3 participants