Forcing noexec as a HAL mount option

rahrah · 06-24-2008, 09:37 PM

Hi,

YAHI (yet another HAL issue) I'm afraid. Does anybody know if
it's possible to force mount options on devices using HAL?
Specifically, I want to force the noexec option on removable media
mounted by HAL. This is a slack 12.0 issue. I haven't tried it
on 12.1, yet.

I've tried variations of this:

Code:

cat /etc/hal/fdi/policy/10-removable.fdi

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
 <device>
   <match key="block.is_volume" bool="true">
       <match key="@block.storage_device:storage.hotpluggable" bool="true">
         <append key="volume.mount.additional_options" type="strlist">noexec</append>
       </match>
       <match key="@block.storage_device:storage.removable" bool="true">
         <append key="volume.mount.additional_options" type="strlist">noexec</append>
       </match>
   </match>
 </device>
</deviceinfo>

With combinations of these things:

s/additional/extra/
s/mount\.//

I've also tried the deprecated volume.policy.mount_option.noexec
option, but that's completely fruitless, too.

The keys all get added to the devices in question, but get ignored
by hal-storage-mount.

As yet, the only way I've managed to force this is by changing
line 70 of hal-storage-mount.c from

#define MOUNT_OPTIONS "nosuid,nodev"

to

#define MOUNT_OPTIONS "noexec,nosuid,nodev"

Is there a better way (without mucking about with KDE)?

Also:

a) Have I understood it correctly that HAL is designed
specifically only to provide a list of valid mount options to some
user proggy like a KDE app? Can any user proggy - given that
it's authorised via a group (eg plugdev) membership to speak to
HAL via the message bus - decide what options to use or NOT to
use and request hald, a root process, to do its bidding?

b) Is it true that whilst HAL provides for a list of allowed mount
options (volume.mount.valid_options), it provides no way of
enforcing important options like nosuid, nodev and noexec (BY
DESIGN)? Is it true that it is up to the discretion of a user
proggy what it uses and doesn't use to mount? So if
hal-storage-mount.c did not define nosuid at line 70, then there
would be no method available in HAL's complex xml config files of
stopping users mounting their disks, and gaining root privs.

c) Does this demonstrate something very broken in HAL's design?
If not, what am I missing?

Cheers,

===Rich

shadowsnipes · 06-25-2008, 05:54 PM

I think what you really want is a custom udev rule.
http://reactivated.net/writing_udev_rules.html

rahrah · 06-26-2008, 01:42 PM

Hi,

Thanks for getting back to me. I guess there are many
ways of auto-mounting, and imposing policies. I really
was posting to see if I was wrong regarding
one's inability to impose system mount policies in HAL
without resorting to patching the hal-storage-mount.c. I'm
still unsure if I'm right or wrong.

I think they (or David Zeuthen) removed volume.policy.mount_option
because people were putting stuff in there that they should have
been devolved to the user proggy, an that broke their/his vision, and
the cleanness of the idea. For me, it makes HAL less of a system.

Thanks, anyway, for getting back to me.

===Rich