[PATCH] set required mount privileges via fdi file

[David Zeuthen]

On Thu, 2006-07-27 at 15:52 +0200, Ludwig Nussel wrote:
> > If you change the privilege name then there is no chance that the
> > PolicyKit daemon knows the HAL daemon is trying to do. And then the
> > separation between policy and mechanism breaks.
> 
> I don't understand. PolicyKit doesn't "know" what hal is trying to do
> anyways.

The point is that it can. For mounting file systems HAL exports four
well-defined privileges

 hal-storage-removable-mount
 hal-storage-removable-mount-all-options
 hal-storage-fixed-mount
 hal-storage-fixed-mount-all-options

see the comments in the files here 

 http://gitweb.freedesktop.org/?p=hal;a=tree;h=643834fa85ee572ef7be497cc28a173bad00b02c;hb=15376ac7c17fa31033adefcfe106935e09b5b0df;f=privileges

on the semantics of each. So, yes, indeed one _hypothetical_ back-end
for the org.freedesktop.PolicyKit service could just poke HAL about the
resource that is passed, e.g.

 hal:///org/freedesktop/Hal/devices/volume_uuid_12345678

and look at e.g. the file system type, the UUID and so forth. I
emphasize _hypothetical_ because, you know, I don't think that's a good
idea for normal desktop use - I really just want to look up a file and
check on normal stuff like UID, SELinux security context or whatever is
available.

Also note that we could have done with just two privileges

 hal-storage-mount
 hal-storage-mount-all-options

and org.freedesktop.PolicyKit would call into HAL to look at
storage.removable and storage.hotpluggable. However, normal use cases is
that we want to differentiate between file systems from 'fixed' resp.
'hotpluggable / removable' media because that's the way desktops works.
Or we could even do with

  hal-storage-mount

provided we changed PolicyKit to take a domain-specific 'options'
parameter, e.g. the Mount() method on HAL would call

 org.freedesktop.PolicyKit.IsCallerAllowedForPrivilege (
   caller=":1.203",
   privilege="hal-storage-mount",
   resource="hal:///org/freedesktop/Hal/devices/volume_uuid_12345678",
   options="mount_fstype='msdos' mount_options='uid=500,utf8'")

and then the org.freedesktop.PolicyKit service would make up it's own
mind about whether said caller is allowed to do that. But that would
make it way too complex for no gain. Hence, these are the tradeoff's
made.

> > The exception is that if you, for example, pass 'uid=502' and the caller
> > has an uid != 502 then we will force using the -all-options privilege
> > because of security reasons. Makes sense, yes?
> 
> That's not what the code in cvs does. The code checks whether uid=
> is specified for a filesystem other than vfat, iso9660 or udf, if so
> it requests hal-storage-removable-mount-all-options. You can pass
> any uid for the three hardcoded(!) filesystems. 'real' filesystems
> don't support uid= so the check is pointless. 

With 'real' file systems I presume you mean owners with owner, group,
world semantics. I do think that you can force both ntfs and hfsplus to
be mounted in a way where uid's are remapped. 

For example, on my Thinkpad laptop as uid=500 I want to access files on
my hfsplus removable disk as uid=501 because I wrote those files as
uid=501 from a Mac system. That's an extremely common use-case in a
heterogenous environment (like a business setting), see some mockups
here

 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

(does anyone know if something like this is actually possible? otherwise
I suspect it might be worthwhile to write a kernel patch for those file
systems...)

> Even for the three
> listed filesystems it doesn't harm as nosuid is used anyways.
> If you pass an invalid mount option you get an
> org.freedesktop.Hal.Device.Volume.InvalidMountOption exception.

Yup, that needs to be fixed then. The point really is that

 volume.mount.valid_options

is the list of mount options we consider to be "safe", e.g. they don't
allow the user to do something which potentially would require more
privileges. Like allow write access to removable media where the uid's
doesn't match up.

    David