GNOME Bugzilla – Bug 696298
Huge directory hierarchy under $HOME/.gvfs/SFTP due to symlink cycle
Last modified: 2018-09-21 17:22:01 UTC
A folder for an SFTP mount in $HOME/.gvfs contains a huge directory hierarchy because the remote folder contains a symlink cycle that was apparently dereferenced when the mirror structure under .gvfs was created.
I don't see a problem here - ~/.gvfs is just a fuse mount for active gvfs mounts, nothing is really created on your disk. We respect symlinks in sftp backend, native GIO clients (Nautilus) should show you that. I see a problem in the fuse daemon though - symlinks are dereferenced indeed. We should fix that. Out of curiosity - what is your use case and what troubles does it make to you?
Created attachment 241830 [details] [review] add symlink support to fuse Add symlink support for fuse (vfs_readlink). Change absolute link path to relative (same as sshfs), because links with absolute path won't work. It can be potential security issue, so we need to discuss it.
Created attachment 241893 [details] [review] add symlink support to fuse Patch fix due to obfuscation code and licence problems.
There's this comment in vfs_readlink(): > /* This is not implemented because it would allow remote servers to launch > * symlink attacks on the local machine. There's not much of a use for > * "readlink" anyway since we don't pass G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, > * so non-broken symlinks will be followed transparently. */ While I understand there's certain risk from files pointing somewhere inside your system or your home directory and could be used to spoof path and possibly destroy your data (by editing files not knowing they're on a local machine), it's all still running with the same UID and I can't imagine how this could be abused some other way. Users are still responsible for manipulating with the data incl. file write, deletion and execution. (Note to myself: shall we mount -o noexec?) One other concern we should take in account - using fuse daemon-provided mount for easy backup. Any modification to symlinks makes backups practically useless. The fact users are not informed about this "feature" is even more alarming, we're constantly getting bugreports where reporters are stating the backup case. The typical SFTP usage is to connect to a remote system where absolute symlinks are very common. We always targetted our FUSE daemon just as a simple fallback though, like a convenient way of opening documents in non-GIO apps, but certainly not as a fully-fledged VFS solution. I see three possible ways of dealing with symlinks: 1. Deference them and present target regular files and directories instead (the current state). This effectively destroys symlinks but retains highest level of security. Broken symlinks are presented as symlinks with no way to retrieve their target (unimplemented vfs_readlink()). Also copying a particular structure will lead to data amount amplification. 2. Translate absolute paths to relative ones, preferably doing some more sanity checks that even non-translated symlinks don't point out of the fuse mountpoint. Again this destroys some data. Reportedly this is the default behaviour for sshfs mounts. 3. Don't touch symlinks at all - insecure but all data are preserved, suitable for the backup case. Please discuss.
Review of attachment 241893 [details] [review]: ::: client/gvfsfusedaemon.c @@ +879,3 @@ +static gchar * +transform_symlink (const gchar *path, const gchar *link) I don't understand the use for all of this. Say you have the fuse mounted at /run/user/1000/gvfs, and you have a symlink at /run/user/1000/gvfs/sftp-mount/the-symlink. What is the likelihood of the symlink starting with "/run/user/1000/gvfs", which is what this function tries to match? It seems more likely that it'd be either "/etc/passwd" (a security attack) or "/home/user/some/file" (random symlink to a file. In these cases we should either just return the symlink value as-is "/home/user/some/file" or convert it to something inside the fuse mount (i.e. ../home/user/some/file similar to what the patch does). The later really only works if the fuse mountpoint represents the root dir of the target system, on the other hand, for sftp which is the main source of symlinks that tends to be true, so it might not be a problem. I think doing the later conversion is probably right, but ignoring the prefix check the code does now it can be much simpler. Just concat the fuse mountpoint + the mount name + the absolute link value and return that. I.e. in the example above: "/run/user/1000/gvfs" + "sftp-mount" + "/home/user/some/file"
(In reply to comment #5) > Review of attachment 241893 [details] [review]: > > ::: client/gvfsfusedaemon.c > @@ +879,3 @@ > > +static gchar * > +transform_symlink (const gchar *path, const gchar *link) > > I don't understand the use for all of this. Say you have the fuse mounted at > /run/user/1000/gvfs, and you have a symlink at > /run/user/1000/gvfs/sftp-mount/the-symlink. > > What is the likelihood of the symlink starting with "/run/user/1000/gvfs", > which is what this function tries to match? It doesn't try to match "/run/user/1000/gvfs". In your case it change absolute path to relative: /etc/passwd to etc/passwd (~ /run/user/1000/gvfs/sftp-mount/etc/passwd) /home/user/some/file to home/user/some/file (~ /run/user/1000/gvfs/sftp-mount/home/user/some/file) So the links are inside the mount without potential security issue. Howeve this patch doesn't deal with relative path so potential security attack could be done using symlink with relative path e.g. ../../../../etc/passwd. > It seems more likely that it'd be either "/etc/passwd" (a security attack) or > "/home/user/some/file" (random symlink to a file. In these cases we should > either just return the symlink value as-is "/home/user/some/file" or convert it > to something inside the fuse mount (i.e. ../home/user/some/file similar to what > the patch does). The later really only works if the fuse mountpoint represents > the root dir of the target system, on the other hand, for sftp which is the > main source of symlinks that tends to be true, so it might not be a problem. You are right, this is unfortunately works only for mounted root dirs. > I think doing the later conversion is probably right, but ignoring the prefix > check the code does now it can be much simpler. Just concat the fuse mountpoint > + the mount name + the absolute link value and return that. I.e. in the example > above: > > "/run/user/1000/gvfs" + "sftp-mount" + "/home/user/some/file" This is simpler, but absolute links with mount name doesn't work in case of backup as tbzatek wrote. Relative links works better in this case, however root dirs have to be mounted...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/202.