Re: Identifying drives/volumes

[Federico Mena Quintero <federico ximian com>]

On Tue, 2004-10-19 at 17:43 +0200, Alexander Larsson wrote:

> Say you have a GnomeVFSVolume that is really a "connected server" that
> points to file:///mnt/cdrom. When you do
> gnome_vfs_volume_monitor_get_volume_for_path(/mnt/cdrom) you will get
> the actual volume for the cdrom, not the connected server volume.

Right.  But I guess the user asked for trouble, anyway, if that happens.

[How would you create such a situation from the user interface?  Can you
do it from Nautilus?]

> I have a question though. How do you propose can_user_see_volume(vol)
> will work? I mean, how would the user specify which volumes are ok and
> which are not?

That's left as an exercise for the reader.  I mean, it's an
implementation detail.  Actually, it's up to the lockdown extension to
decide that :)

Say you have a configuration file that describes what the user may see.
It could be a config file, or something you grab off of LDAP, or
whatever.

Say you are in a company, and want your employees' boxes to be locked
down so that they can only see their home directories, the floppy, and
the company-wide NFS share:

<lockdown>
  <visible-volume base="/mnt/floppy"/>
  <visible-volume base="/mnt/nfs"/>
  <visible-folder base="/home/username"/>
</lockdown>

[Presumably, "/home/username" is generated for each user... you get the idea]

The extension would turn those paths into URIs and implement
GtkFileChooserExtension::is_volume_visible() by simple string
comparisons, and ::is_path_visible() by testing whether one of the
visible-folder items in the XML above is an ancestor of the path that is
being tested.

Or maybe I'm totally on crack, and this is just not the way to implement
lockdown for the file system.  What would Nautilus do?  Presumably it
has requirements that are very similar to the file chooser's.

  Federico