GNOME Bugzilla – Bug 586129
can't connect to CIFS server if there are no read perms on root-folder
Last modified: 2011-03-18 14:31:48 UTC
Please describe the problem: Using nautilus or gvfs-mount, I cannot connect to a Windows share where my user has no read permissions for the top-level directory (the one named as the service). Samba works ok. Steps to reproduce: 1. obtain a suitable smb server with no read perms on the top-level folder of a service for a given user 2. gvfs-mount 'smb://domain;username@servername/servicename' 3. supply your domain and password when prompted Actual results: You are re-prompted for your password (and realm/domain if omitted) repeatedly until I give up and ^C. Expected results: I would expect it to be mounted. Does this happen every time? Yes. Other information: Originally reported at <http://bugs.debian.org/533417>. In my case although my user cannot read the list of files in the top-level directory, I know there is a subdirectory "unix" to which I can traverse and read the contents. Using samba: smbclient -U user //server/service works. 'ls' in the interactive samba client fails. 'cd unix' works, subsequent 'ls' works. Similarly, smbclient -U user //server/service -D unix performs the initial 'cd' and then an initial 'ls' works fine. However, providing the subdir name on the gvfs path does not help, i.e. gvfs-mount 'smb://domain;username@servername/servicename/unix' still fails. Note that I can connect to a different CIFS server which does not have this quirk of permissions on the top-level folder just fine with smbclient or with gvfs via gvfs-mount or nautilus. The working server is Windows Server 2003 R2 3790 Service Pack 2, the failing server Windows Server (R) 2008 Enterprise 6001 Service Pack 1. (although I don't think that is the issue)
my windows admin has just added read/list/execute permission for a group my userid belongs to to the "servicename" directory. The result is that gvfs-mount works. At the same time, he turned on something called Access-Based Directory Enumeration (ABDE) which means the output of listing the directory is restricted to directories I have permission to traverse into afterwards. I don't think that makes any difference on the wire, I believe it to be entirely server-side filtering. So: best-case, we've pinned down the bug (needed list rights in servicename dir); worst-case, ABDE is relevant.
I can now reproduce this on my enterprise network. I find it suspicious that do_mount treats EPERM as EACCESS. Actually EPERM shouln’t be treated as an error when mounting.
Fixing do_mount as I just described allows gvfs-mount to work (with glitches). But it is still not possible to access the mount, even subdirectories in which I have read access.
After further testing, it doesn’t return EPERM but EACCESS. In which case I wonder whether stat()ing the root directory is the correct thing to do; there is no way to differentiate an incorrect password from a missing permission.
Created attachment 176854 [details] [review] Check permissions in the original directory This is a patch by Tomas Bzatek, with a small addition from myself. With this patch, the file/directory passed at mount time is stat()ed, instead of the root directory. As Tomas added: “we might need to fall back to NULL path when first stat fails”. I don’t think it is necessary - in the end you might mount the share corresponding to a directory the user can’t go into anyway. Note that such mounts are not accessible in gvfs-fuse. This is because FUSE (and POSIX, IIRC) requires directory traversal, and therefore to be able to read the root directory. Maybe the gvfs-fuse daemon could set the execute bit without the read bit for this case - but it looks like a separate bug anyway.
(In reply to comment #1) > At the same time, he turned on something called Access-Based Directory > Enumeration (ABDE) which means the output of listing the directory is > restricted to directories I have permission to traverse into afterwards. I > don't think that makes any difference on the wire, I believe it to be entirely > server-side filtering. > > So: best-case, we've pinned down the bug (needed list rights in servicename > dir); worst-case, ABDE is relevant. I don't think it makes a difference, you should be able to attempt to mount hidden share anyway.
(In reply to comment #5) > Created an attachment (id=176854) [details] [review] > Check permissions in the original directory > > This is a patch by Tomas Bzatek, with a small addition from myself. With this > patch, the file/directory passed at mount time is stat()ed, instead of the root > directory. Thanks for testing, Josselin! > As Tomas added: “we might need to fall back to NULL path when first stat > fails”. I don’t think it is necessary - in the end you might mount the share > corresponding to a directory the user can’t go into anyway. Right, but when user specifies a non-existent directory (either by mistake or from an old bookmark) this would reject the whole mount operation. I've added a FIXME in the code. I've pushed the patch nevertheless as it's useful in the state it is now. > Note that such mounts are not accessible in gvfs-fuse. This is because FUSE > (and POSIX, IIRC) requires directory traversal, and therefore to be able to > read the root directory. Yeah, this is a downside, however cd to a nested directory should do the trick. I don't think that stripping the inaccessible part of the path away is the way to go, let's see what the user experience will be.
commit c8bbe04f4e2a7d5457f01049abb700c72af702dd Author: Tomas Bzatek <tbzatek@redhat.com> Date: Fri Mar 18 14:27:09 2011 +0100 smb: Add support for default location This is actually a workaround for inacessible root of the share. By setting default location to a user-specified path Nautilus will go to this folder by default, leaving errors from inaccessible root behind. https://bugzilla.gnome.org/show_bug.cgi?id=586129
(In reply to comment #7) > > Note that such mounts are not accessible in gvfs-fuse. This is because FUSE > > (and POSIX, IIRC) requires directory traversal, and therefore to be able to > > read the root directory. > Yeah, this is a downside, however cd to a nested directory should do the trick. > I don't think that stripping the inaccessible part of the path away is the way > to go, let's see what the user experience will be. The consequence is clear: Openoffice (and several other software) simply refuse to open a file inside such a mount.