Since you haven't got a reply let me outline some possibilities.

Firstly, I'll describe the drive insertion process, so you know where
all the funny subsystem names fit together:
 - the "kernel" detects the inserted drive and calls a "hotplug" program
 - the common hotplug program is "udev"
 - udev looks up udev rules, perhaps setting environment variables for
use by subsequent programs
 - for a USB disk these rules result in a "dbus" message
 - the graphical system ("gnome", "kde", etc) sees these messages, does
some user interface goodness, and calls "udisks"
 - "udisks" calls "polkit" to see if the operation is allowed
 - "udisks" calls the "kernel" to mount the disk
 - the files appearing on the disk have the usual "modes", "ACLs", and
"SELinux context".

Now you can change either udev or polkit rules to prevent the disk being
mounted at all. udev to stop the disk ever being seen and then to turn
the disk off is probably the best way. There's a special "authorized"
file under /sys for each USB drive to allow that.

As far as I can tell you can't use udev or polkit to determine mount
options. You might be able to strip the "w" attribute off
the /dev/sd?[a-z]+ USB storage device using udev. See the MODE
parameter.

You'll be thrilled to hear that with so many moving parts that the mount
options are hardcoded into the file src/device.c of the udisks package.
There is one twist: if the disk is seen in /etc/fstab then the
parameters there are used. That's not particularly useful in this
situation.

Note that what you want isn't strictly the drive to be mounted with "ro"
but for no files to be able to be written to the drive. So you may be
able to use ACLs or SELinux to achieve your goal.

Personally, I'd start with a SELinux rule covering the /media directory
and work my way back from there, ending with an altered udisks-daemon
program. The reason for that is the SELinux and ACLs are security
constraints and their designers have thought long and hard about
preventing people working around them. For example, they'll still work
even if there is a graphical manager that mounts the disk directly
rather than using udisks.

Let us know how you go, Glen

-- 
 Glen Turner <http://www.gdt.id.au/~gdt/>

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to