-
Notifications
You must be signed in to change notification settings - Fork 349
Add new mount option to allow bind mounting symlinks #1761
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
Comments
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 26, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 26, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 26, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 26, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 26, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 27, 2025
This option enables bind-mounting a source symbolic link itself (not its target) onto a destination path. If the destination path is also a symbolic link, it is replaced by the mount rather than being dereferenced. This is useful for precisely controlling symlink handling during mounts, such as when needing to overlay a container's symlink with a mount of a host's symlink. The implementation ensures that if the source is a symlink and this option is active, the symlink's nature is preserved in the mount. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 27, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 27, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 27, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 28, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 28, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/crun
that referenced
this issue
May 29, 2025
Introduce `src-nofollow` and `dest-nofollow` bind mount options for more precise control over symbolic link handling. The `src-nofollow` option enables mounting the source symbolic link itself, rather than its target. The `dest-nofollow` option ensures that if the destination path is a symbolic link, the mount operation replaces the symbolic link itself, instead of dereferencing it and mounting to its target. Closes: containers#1761 Signed-off-by: Giuseppe Scrivano <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, when attempting to bind mount a volume onto a path that is a symlink, crun resolves the symlink and mounts the volume onto the symlink's target. This behavior is not always desirable, as discussed in containers/podman#25947.
This issue proposes the addition of a new mount option in crun. This option would allow users to specify that if the mount point is a symlink, the bind mount should occur over the symlink itself, rather than its target. This would be analogous to using
O_NOFOLLOW
orRESOLVE_NO_SYMLINKS
when opening or resolving paths.The text was updated successfully, but these errors were encountered: