Re: [PATCH] computer:/// should display all drives, not only user-visible ones

[David Zeuthen <david fubar dk>]

Hi,

Sorry for the late reply,

On Thu, 2006-06-01 at 10:19 +0200, Alexander Larsson wrote:
> > So I'm not really sure why we want this difference you are describing.
> > In fact I'd argue that we indeed want to show volumes from e.g. the
> > internal hard disk for e.g. your Windows and OS X partitions. 
> > 
> > And this indeed requires a GnomeVFSDrive because the partition may not
> > be mounted and we only have a GnomeVFSVolume for a GnomeVFSDrive when
> > the partition the GnomeVFSDrive represents is actually mounted (that's
> > my understanding of the how Gnome VFS works).
> 
> The initial design for drives was to represent devices that use
> removable media (such as cdrom drives, floppy drives, usb card readers,
> etc). For these devices the operations on the device are "natural" to
> the user. Its true that one can also view them as just "possible
> mountpoints for volumes", which means you could have a drive for your
> OSX or windows partition. However, when you expose this in the UI you
> suddenly turn a very explicit obvious hardware mapping into a way to
> expose the much more vague and complicated unix operation of "mounting a
> filesystem". I.E. you remove the mapping from icons in the UI to
> hardware units you can put stuff into.

As a user I'm not really sure there is a huge difference between
"Macintosh HD" and "1GB Compact Flash media". Both contains files I'm
interested in using, I don't care where they come from.

> If you take the view of a non-unix person (i.e. one unaware of the
> details of mountpoints etc) using a Gnome desktop with a separate HD
> you have basically three cases. Either the partition is mounted, the
> user is allowed to mount the partition, or the user isn't allowed to
> mount the partition. In the first case we clearly should show a volume
> icon, and in the last case i argue that we should never show a drive
> icon (it would do nothing but confuse people). 
> 
> The question is what to in the second case. In an ideal desktop system I
> don't think that state really is very useful. What non-sysadmin-related
> use would you have for not mounting that volume if you are allowed to
> mount it anyway? In the case on a non-ideal unix system the question
> gets complicated and turns into a question about whether the mountpoint
> is an "internal implementation detail" of the filesystem mount tree or
> not, and this becomes very similar to the question whether to expand
> symlinks or not (don't expand /home to /mnt/hdb/home, but expand
> ~/Desktop/music to ~/Documents/MyMusic). Some cases are simple, you
> never want to display /, /proc, /sys, /dev/pts, /boot, etc. However, for
> others things are not so easy. I have for instance /mnt/hdb1 on my
> system where i have symlinks like /opt -> /mnt/hdb1/opt. I wouldn't want
> to display this.
> 
> Whether to show such drives or not is clearly a complicated,
> system-dependent issue and should be solved in the lower layers, and not
> solved in each app using gnome-vfs.
> 
> The change that resulted in this being an acute problem was that we
> decided to hide drives that support auto-mount in all places but
> computer:// by using the is_user_visible flag of the drive. Doing this
> means that flag is used for that and can't also be used to flag whether
> a drive is "internal" or not. I think just not having drive objects for
> internal mountpoints is the easiest solution to this.

Well, the reality is that lots of people dual or triple boot and they
have files they care about on the Macintosh and Windows hard drives. And
I don't think it's uncommon at all to attach removable drives formatted
with e.g. HFS+ or NTFS.

If security (we can't let the user automatically get full read access to
e.g. an hfs+ fs on the Mac harddisk) and availability of file system
driver code (NTFS write support is still not widely available) wasn't a
concern this would be easy; we'd simply automount these with uid=500 and
be done with it. We want this such that the user can access his files in
e.g. /Users/davidz which has a different uid on the Mac OS X system
(such as uid=1000).

However, things are a lot more complicated.

For example, if you have full write access (like when you mount with
uid=500) to the root partition of another operating system as an
unprivileged user (with uid=500) you can essentially change the password
database on that fs and, bingo, what was previously a secure system
before you put Linux (or whatever on it) now has issues. 

There's also things like EAL [1] that is important, e.g. we should be
able to totally lock down the system such that you can't use it for
anything, not even access your removable media. 

Surely, in this situation, we want to still show to the user that he got
a card reader plugged in but that the organizational policy of his
employer (or whatever) prevents him from using it. Perhaps, in the name
of usability, we might give him a button titled "Request permission to
use device" (would file a request to the IT department) when he clicks
it or, if it's an administrator, he can put in his password or
authenticate in other ways.

This is where usability and security meets, fighting each other like
cats and dogs. Can you see the dilemma? 

Like it or not, this is from the real world [2] and bills like
Sarbanes-Oxley etc. don't make this *any* easier. This is why I started
PolicyKit. PolicyKit and gnome-mount will help solve this problem though
not in a very elegant way [3] but it will provide a "one-time-click"
"solution" to the problem. 

Some might say the user looses here (just look at the recent Microsoft
Vista reviews where the user is bombarded with dialogs) but we're still
left with the dilemma mentioned above. And we do want (I believe) GNOME
to be a viable contender on the desktop and that means we need to
support lock-down and things like EAL and Sarbanes-Oxley. Just as we
want it to work for home users who just wants to access that movie on
the NTFS or hfs+ partition from his home directory on "that other
operating system".

The approach taken by PolicyKit and gnome-mount is best compromise I've
come up with so far. I'm not convinced it's perfect though, and I
haven't had time to complete it yet though things are slowly moving
forward.

So what am I trying to say? I'm trying to say it makes sense to show all
drives and their mountable file systems notwithstanding the user might
be allowed to access them. Because if they're not privileged they should
at least get a chance to see the drive is there (otherwise you get "My
drive didn't show up! Is the computer broken?") along with an
explanation why they can't access it maybe even with a possibility to
auth for access.

> > So I think what you want is to hide is exactly volumes that are mounted
> > on traditional FHS mount points, e.g. /, /usr. I can't see why we should
> > enforce this policy in Gnome VFS when the bits above (e.g. Nautilus,
> > Filechooser) can handle this much better?
> 
> I don't understand how you think nautilus can handle this better? 

Agreed, yea, probably GNOME VFS would know best.

    David


[1] : http://en.wikipedia.org/wiki/Evaluation_Assurance_Level

[2] : http://www.pbs.org/cringely/pulpit/pulpit20040916.html
      Search for "epoxy".

[3] : See
 http://people.freedesktop.org/~david/perm-override/gnome-mount-perm-override-1.png
 http://people.freedesktop.org/~david/perm-override/gnome-mount-perm-override-2.png