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