Checking volumes and storage devices for fstab entries

David Zeuthen david at fubar.dk
Thu Dec 14 20:52:45 PST 2006


Martin Pitt wrote:
> Hi,
> 
> we want to properly integrate the mounting of fixed disks into the
> Gnome UI. So far we just volume.ignore'd them all, but in the future
> we want to have gnome-mount mount fixed partitions as well when called
> as root (using PolicyKit, or gksu gnome-mount).
> 
> However, we still want to volume.ignore partitions which are
> automatically mounted from fstab. Since fstab information might be
> interesting for other purposes, too, I wrote a patch for the volume
> and storage probers to add two new properties
> linux.fstab.{mountpoint,options}. The patch recognizes device name
> symlinks, and the UUID= and LABEL= syntax.
> 
> With that, the storage policy FDIs can nicely match for 'defaults',
> but no 'noauto', or a single 'auto' option, etc.
> 
> I attach my initial shot at the patch. It's not nice yet for upstream
> adoption, since the duplicated function should be factored out into a
> library that is linked to both probes, and I didn't update the spec
> yet. I would like to ask for some feedback, and if you guys would
> consider adopting this at all. If so, I'll pour some niceness over the
> patch and report back.

So the way it works to day is

  - Mount() on HAL refuses to mount a device if it's listed in /etc/fstab
    and supports both symlinks (e.g. /dev/disk/by-label/SomeLabel), UUID=
    and LABEL=. Today it returns o.fd.Hal.Volume.PermissionDenied

  - gnome-mount has the same code (copy-paste :-( ..) and if it sees the
    device is in /etc/fstab it uses e.g. "mount /dev/sda" to attempt to
    mount

How about

  1. Changing HAL so it returns o.fd.Hal.Volume.PermissionDeniedEtcFstab
     instead of o.fd.Hal.Volume.PermissionDenied if a device is listed
     in /etc/fstab.

  2. Allowing sufficiently privileged users to mount even though the
     device is in /etc/fstab (e.g PK privilege or uid 0). It would only
     work if the same mount options as in /etc/fstab are passed so in
     effect it would ignore the passed mount options. It's a bit ugly
     but I think it's OK a mechanism like HAL respects system-wide
     policy files like /etc/fstab.

  3. Making gnome-mount act on o.fd.Hal.Volume.PermissionDeniedEtcFstab
     by first trying mount(1) (like today) and if that fails then
     and mount through HAL after gnome-mount has gained privileges. That
     way we could also delete all the /etc/fstab cut-n-paste parsing code

Also note that gnome-vfs2 might need some fixing since I'm not sure it 
works totally reliable for devices listed in /etc/fstab. The problem is 
that right now gnome-vfs2 keeps a Volume icon for a /etc/fstab volume 
even though there is no device to back it. That should probably be 
changed as it simply don't make sense from an usability point of view... 
Anyway, if you think this is a good idea I can fix this up too.

Your idea sounds nice I think; it provides admins and users with an easy 
way to provide system-wide managed options for storage devices. E.g. if 
I'm an admin I can simply add a line to /etc/fstab and then only those 
options will be used.

      David



More information about the hal mailing list