Snapshot automount (.zfs) still fails under chroot (OpenSSH ChrootDirectory) #8903
Comments
|
Run |
|
In |
|
for logging run |
|
Mounting all snapshots manually ( This issue is only occurring when trying to auto-mount the snapshots through a chrooted SFTP, because the auto-mounter is using the client’s view of the filesystem (chrooted to |
|
@behlendorf In #3778, you mentioned the ability to get full mount path in a chroot was resolved “in the 0.7 series,” but I didn’t see any specific linked commits, or other indication of when exactly it landed in 0.7 (comment date puts it at 0.7.6 or prior). Was it reverted out at some point, or does this potentially appear to be a different enough circumstance based on how OpenSSH might be performing the user chroot? I also noticed somewhat similar issue #3512 regarding Linux namespace usage preventing full path resolution of mounts or snapshots in containers, although in this case OpenSSH should only be chrooting the user, not in a different namespace, so I’m a little stumped – not running in any containers here. |
|
@mattgarber multiple issues were resolved regarding the automounting of snapshots. Unfortunately, automounting in your circumstance appears not to be handled. As you correctly pointed it, it appears to be because the |
|
@behlendorf Thanks for taking a look and confirming this as a different case. Do you remember if there was a reason the Is there an easy/good way to “clearly” determine the path isn’t valid, or is the best solution to do a quick compare between the values of |
|
@mattgarber if possible, would you mind verifying the proposed fix in #8966. |
|
@behlendorf @kusumi Thank you! Was just able to confirm on a fresh installation that the proposed fix #8966 eliminates the issue preventing automounting snapshots in this chroot. |
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes openzfs#8903 Closes openzfs#8966
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes openzfs#8903 Closes openzfs#8966
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes openzfs#8903 Closes openzfs#8966
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes openzfs#8903 Closes openzfs#8966
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes openzfs#8903 Closes openzfs#8966
Chroot'd process fails to automount snapshots due to realpath(3) failure in mount.zfs(8). Construct a mount point path from sb of the ctldir inode and dirent name, instead of from d_path(), so that chroot'd process doesn't get affected by its view of fs. Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Tomohiro Kusumi <[email protected]> Closes #8903 Closes #8966
System information
Describe the problem you're observing
When attempting to browse auto-mounting ZFS dataset snapshots (.zfs/snapshot directory) over a chrooted SFTP (OpenSSH’s
ChrootDirectorydirective), snapshot access fails with the following error:WARNING: Unable to automount /.zfs/snapshot/2019-06-13T221233/tank/backups/test01@2019-06-13T221233: 512Browsing snapshots in this manner works as intended if
ChrootDirectoryis not set (not a workable solution, due to needing to restrict SFTP client access to the filesystem), and also works correctly on FreeBSD (11.2-RELEASE, 12.0-RELEASE), presumably because of differing methods of auto-mounting snapshot access.This appears to be extremely similar to #3778, and @behlendorf indicated various fixes landing in 0.6.x and 0.7.x, although perhaps it wasn’t fully resolved for all kinds of chroot? The error is clear, in that the
mountoperation is being called on the SFTP client’s view of the filesystem (where/tank/backups/test01appears as/), even though it should be resolved outside of the chroot.I first ran into this issue on Ubuntu 18.04, running distro-provided zfs/spl 0.7.5, although attempted this reproduction on Debian with the latest 0.8.0 release to see whether the #3778 discussion/fixes were landed after Ubuntu’s version.
Describe how to reproduce the problem
Create a new dataset for hosting restricted client content, e.g.
tank/backups/test01, mounted at/tank/backups/test01.Create some dummy files, and create a symlink at the top of the dataset, pointing to the hidden snapshots directory:
ln -s .zfs/snapshot snapshots. (The symlink is only so that SFTP clients don’t have to explicitly view hidden files, it’s not a prerequisite for reproducing the issue!)Create a few snapshots of the dataset:
zfs snapshot tank/backups/test01@one,zfs snapshot tank/backups/test01@two.Create a test user (e.g. test01) and configure OpenSSH to restrict access for that particular user, including ChrootDirectory, and restart
sshd. E.g.:Connect via SFTP as specified test user. Verify that dummy files and directories are successfully browsable.
Change into the
snapshotssymlink (.zfs/snapshot), and verify that snapshots list is accurate. (The symlink is only so that SFTP clients don’t have to explicitly view hidden files, it’s not a prerequisite for reproducing the issue!)Attempt to enter one or more snapshot directories. No content will appear, and kernel log on host system will include one or more errors similar to above:
WARNING: Unable to automount /.zfs/snapshot/one/tank/backups/test01@one: 512.Include any warning/errors/backtraces from the system logs
The text was updated successfully, but these errors were encountered: