[PATCH] set required mount privileges via fdi file

Ludwig Nussel ludwig.nussel at suse.de
Thu Jul 27 06:52:24 PDT 2006


On Saturday 22 July 2006 19:24, David Zeuthen wrote:
> On Wed, 2006-07-19 at 10:16 +0200, Ludwig Nussel wrote:
> > hal-storage-mount currently hardcodes the privileges required to
> > mount a volume. By storing the required privilege in hal instead
> > it's possible to set volume specific privileges via fdi file. So in
> > order to only allow Dave to mount "Dave's usb key" you just have to
> > create an fdi file that overwrites the default for this specifc
> > device.
> 
> Nope, this is just plain wrong. See my other mail here
> 
>  http://lists.freedesktop.org/archives/hal/2006-July/005665.html
> 
> The point is really that you want the PolicyKit daemon to make this
> decision. And it can happily do this as long as we still pass the
> resource, e.g. the HAL UDI for the volume.

There is no architectural change with the patch. Right now the
privilege is hardcoded into the hal helper C code, the patch just
makes configurable what gets requested by the hal helper. PolicyKit
still decides whether or not the user possesses that privilege.

> 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.

> > I don't understand what the intention behind the "uid=" special case
> > was. "uid=" is not supposed to be included in the list of allowed
> > options if the fs doesn't support it anyways.
> 
> You mean volume.mount.valid_options? It just specifies what options you
> can use and if an option has a trailing '=' character it means you can
> set values. If you use options outside this the HAL will use the 
> 
>  hal-storage-removable-mount-all-options
> 
> privilege instead of 
> 
>  hal-storage-removable-mount
> 
> privilege for mounting removable media. 
> 
> 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. 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.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/




More information about the hal mailing list