should not list mounts that the user doesn't have permission to use

[Andy Stallwood]

Binary package hint: gvfs

Hi,
As per the comment from Seb Bacher (see https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/209926), I am raising this specific part of the bug under gvfs.

After upgrading to Hardy, all 3 of my network drive maps (mounted via /etc/fstab) are shown as icons on the desktop to both my users, when on Gutsy it only showed icons for the drives I (andy) had permissions to read, and the same (in reverse) for my second user (jo). The share I don't have permissions to won't actually open (which is exactly correct), but the icons are still shown on the desktop for all 3.

My /etc/fstab file is as follows :-

#Andy's Network Drives
//buffalo/shared /media/AndySharedDocs cifs credentials=/root/.andycredentials,iocharset=utf8,uid=andy,gid=andy,dir_mode=0700,file_mode=0700 0 0
//buffalo/andy /media/AndyDocs cifs credentials=/root/.andycredentials,iocharset=utf8,uid=andy,gid=andy,dir_mode=0700,file_mode=0700 0 0
#Jo's Network Drives
//buffalo/jo /media/JoDocs cifs credentials=/root/.jocredentials,iocharset=utf8,uid=jo,gid=jo,dir_mode=0700,file_mode=0700 0 0

Output from the 2 commands :-

andy@andy-laptop:~$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

andy@andy-laptop:~$ apt-cache policy gvfs
gvfs:
  Installed: 0.2.2svn20080331-0ubuntu1
  Candidate: 0.2.2svn20080331-0ubuntu1
  Version table:
 *** 0.2.2svn20080331-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

andy@andy-laptop:~$ apt-cache policy gvfs-backends
gvfs-backends:
  Installed: 0.2.2svn20080331-0ubuntu1
  Candidate: 0.2.2svn20080331-0ubuntu1
  Version table:
 *** 0.2.2svn20080331-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
andy@andy-laptop:~$

[Andy Stallwood (andy-stallwood)]

This shows the permissions on the mounted drives. As you'll see I shouldn't get an icon on my desktop for "JoDocs", and jo shouldn't get icons for "AndyDocs" or "AndySharedDocs"

andy@andy-laptop:/media$ ls -al
total 20
drwxr-xr-x 8 root root 4096 2008-04-03 21:25 .
drwxr-xr-x 21 root root 4096 2008-04-03 21:20 ..
drwx--x--x 26 andy andy 0 2008-04-03 20:27 AndyDocs
drwx------ 9 andy andy 0 2008-03-28 17:34 AndySharedDocs
drwx------ 10 jo jo 0 2008-03-29 13:57 JoDocs
(I've deleted cdrom0 etc. from the output to make it easier to read)

Also gvfs has been updated. New versions show below. I still have the issue though.
andy@andy-laptop:~$ apt-cache policy gvfs
gvfs:
  Installed: 0.2.2svn20080403-0ubuntu1
  Candidate: 0.2.2svn20080403-0ubuntu1
  Version table:
 *** 0.2.2svn20080403-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
andy@andy-laptop:~$ apt-cache policy gvfs-backends
gvfs-backends:
  Installed: 0.2.2svn20080403-0ubuntu1
  Candidate: 0.2.2svn20080403-0ubuntu1
  Version table:
 *** 0.2.2svn20080403-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

[Sebastien Bacher (seb128)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=526320

[Sebastien Bacher (seb128)]

upstream made that work only for subdirs because the code listing the mountpoints is not asynchronous and then don't want to get everything blocking when trying to access() the mountpoint for not responding nfs mounts for example, the change fixes the ltsp case though so it's worth getting as an update

[Sebastien Bacher (seb128)]

TESTCASE for the subdir scenario described
- create a testcase directory in media for example
- mount something in /media/testcase/directory, and easy way is to edit fstab to change your cdrom mountpoint to that directory
- change the testcase directory to be owned by your user and have permissions 700
- open a session as an another user
- notice that the cd is listed on the desktop
- install the update, restart the session and notice that the cd is not listed now

[Andy Stallwood (andy-stallwood)]

That's excellent news. Thanks Seb (and whoever fixed it).

How do I go about getting the update? I've done an update of Hardy (via Update Manager), and didn't get any updates to ltspfs or glib. Do I need to wait for it to be published as a Ubuntu Update, or am I not doing something write.

Andy

[Sebastien Bacher (seb128)]

the update is a stable update candidate, once an ubuntu-sru member accepts it it'll be available in hardy-proposed, then after a week if the testing confirms the update is alright it'll be moved to hardy-updates

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Martin Pitt (pitti)]

I can verify this, assinging for me for this purpose.

[Nubae (dvanassche)]

I can verify that this indeed fixes the issue. Users now only see what is owned by them in Places.

[Martin Pitt (pitti)]

Verification failed for me. I logged in as 'martin' and in another session as 'joe', and plugged in an USB stick when 'joe' was active. Then I switched back to 'martin' and got an icon and a (corrupt) nautilus window for the USB stick, together with an "Could not be displayed, inaccessible" error message.

[Oliver Grawert (ogra)]

an additional fix in ltspfs was missing, a new ltspfs package is uploaded to hardy-proposed

[Martin Pitt (pitti)]

I don't understand how this ltspfs fix should change anything? Permissions of mount point directories are irrelevant, they are replaced by the mounted partition's root dir permissions after mount. So how on earth could this change the situation? Or do you do the chmod *after* the mounting? That would be wrong, since you'd change permissions on the mounted device (which you shouldn't do, at least not without asking the user).

[Martin Pitt (pitti)]

To be completely candid, this gvfs patch is bogus. Can we please do something like http://bugzilla.gnome.org/show_bug.cgi?id=526320#c20 ? I'm happy to work on this if nobody else wants to.

[Martin Pitt (pitti)]

Accepted ltspfs into hardy-proposed, please test.

[Martin Pitt (pitti)]

Oliver, please upload the fix into Intrepid.

[Martin Pitt (pitti)]

I'll try to come up with a better patch.

[Oliver Grawert (ogra)]

synced new upstream into intrepid, containing the fix

[Martin Pitt (pitti)]

I copied the current hardy-proposed version of glib2.0 to hardy-updates, so that the ltsp case gets fixed. I keep the bug open, though, since the general case is not solved yet.

[Oliver Grawert (ogra)]

the ltspfs package in proposed works fine, all fixes we have there are applied upstream as well and included in the latest version we synced from debian for intrepid, please copy over ltspfs from -proposed to -updates

[Martin Pitt (pitti)]

Copied to hardy-updates.

[Andy Stallwood (andy-stallwood)]

I can confirm that my original bug is now fixed with this update. I only see network drives on my desktop (and in Places) which I have permissions for, and likewise for my other users. Well done, and thanks everybody.

Andy

[Michael Blinn (mblinn-gmail)]

With ltspfs updates I still see this bug, or a variant thereof. I currently see two others' floppy0 icons on desktop (with gconf-editor apps->nautilus->desktop->volumes_visible checked) and also in Places menu. Not sure if it's relevant, but I have 12 users logged in right now, and am only showing 2 floppies.

mblinn@www:~$ apt-cache policy ltspfs
ltspfs:
  Installed: 0.5.0~bzr20080109-3ubuntu3
  Candidate: 0.5.0~bzr20080109-3ubuntu3
  Version table:
 *** 0.5.0~bzr20080109-3ubuntu3 0
        500 http://us.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     0.5.0~bzr20080109-3ubuntu2 0
        500 http://us.archive.ubuntu.com hardy/main Packages

[Michael Blinn (mblinn-gmail)]

I can confirm that this bug is now fixed. I had to reboot all the clients with local devices; after doing so the icons went away. Thanks for all the hard work in squashing these bugs!

[RYUDO (giorgiolago)]

this bug its not solved for me, i made all updates [all repositorys] on system and chroot and the problem still.
i make a test in vmware to see...

[Sebastien Bacher (seb128)]

did you read the previous comments before adding a new one? the issue is fixed for a specific case but not for the standard media mounts yet

[RYUDO (giorgiolago)]

Sebastien, I read the comments passed, but I do not speak English, I wonder if the team has a date for when this bug will be resolved serious? in my sense the ltsp of the hardy could have left with a bug as grotesque as this. We are unable to make use of local devices as they appear repeatedly in the desktop of all users.
Why was marked as fixed if indeed the bug has not been resolved? make a trial: install vmware even in an environment ltsp devices with local and you'll see after all the updates that the bug still there.
switch from the stat fixed to not fixed

[Sebastien Bacher (seb128)]

the ltsp case is supposed to be fixed, could you describe what mount is listed, where it's mounted and what permissions are used on the directory?

[Oliver Grawert (ogra)]

well, out of ten people that tested the fix in #ltsp al ten didnt have the issue anymore after upgrading, i suspect there is something special in your setup or hardware that makes up teh difference since you are really the first person to still see the issue after upgrading the packages ... lets try to find that difference. when we talked in #ltsp you only had floppies on your desktop, does it happen for all devices or only for floppies (which might be handled differently by either glib or ltspfs ?

[RYUDO (giorgiolago)]

ogra, the problem happens with all Removable media such as diskettes and cdroms pendrivers.

[Oliver Grawert (ogra)]

i did a bit research on that open issue and apparently it happens for people using ldap auth with adding all users to the "users" group and not creating a default group the user is assigned to ...

in a default setup with one group per user as the default it will still work ... the problem here is that the ltspfs piece (lbmount) that does the local binding to
/media/$USER/<device> is suid root, which in turn means the mountpoint is owned by root and all access control happens through the group permissions ... the proper way to work around that is to have the user owned groups and set that as default group as its handled by default in the adduser setup of ubuntu.

[Ronald van Engelen (ronalde)]

Is it possible to think of a nicer solution for this problem?

We really want to use "Domain Users" as the default group for our users, who can choose to login either to a proprietary desktop or ubuntu. For now there are more proprietary desktops than free ones.

[Juha Erkkilä (juha-erkkila)]

Here's a patch to ltspfs that changes /media/* directories owner to user, group to user's primary group, with 700 permissions. I don't know why it is not done this way, so this might break something, but if you suffer from this bug this patch should fix it with no known ill effects (it's been deployed on many similar installations so far).

[Oliver Grawert (ogra)]

did you test that workaround ? lbmount has to run suid root, with that patch the directory will be owned by root and have 0700 permissions.

[Václav Šmilauer (eudoxos)]

Wouldn't it help to run lbmount sgid (not suid) root, determine user from username (not groupname) and change permissions accordingly? (Sorry if that wouldn't work, I am newcomer to this bug)

[Juha Erkkilä (juha-erkkila)]

Yes, the patch was tested. lbmount is run setuid root indeed, but pwent contains real user information, not effective user information (it does call "pwent = getpwuid(uidReal)" previously), so the directory will be owned by the correct user.

[Martin Pitt (pitti)]

I proposed an (IMHO) better patch upstream now. Will wait for some comments, and then upload it to jaunty.

[Launchpad Janitor (janitor)]

This bug was fixed in the package glib2.0 - 2.19.2-0ubuntu2

---------------
glib2.0 (2.19.2-0ubuntu2) jaunty; urgency=low

  * Add 05_hide_inaccessible_mounts.patch: Do not show /media mounts which are
    inaccessible to the user. This only works on local block devices, though,
    since others (like remote mounts) have the risk of hanging on stat().
    (LP: #210379)

 -- Martin Pitt <email address hidden> Thu, 04 Dec 2008 11:11:30 -0800

[Martin Pitt (pitti)]

Seems that this didn't actually cause a lot of stir, so let's not worry about hardy unless someone convinces us to do an SRU.