HAL policies for port. music players

[David Zeuthen]

On Sun, 2005-01-09 at 13:15 -0500, Jeff Spaleta wrote:
> On Sun, 09 Jan 2005 12:56:59 -0500, David Zeuthen <david at fubar.dk> wrote:
> > This means: For a specific device (USB vendor_id 0x0d7d, USB
> > product_id 0x1600), HAL/fstab-sync will attempt to use the mount
> > point /media/my_mount_point (if it's not taken already!) and
> > add the mount options uid=555 and gid=555, which of course only
> > applies to vfat. 
> 
> Is there any way inside hal policy to build logic based on which user
> is console user at the time?  Console user is a special desgination
> after all, and it seems perfectly reasonable to me that you can run
> into multi-user networks where the competent administrator wants to
> have the device appear differently based on who the console user is.
> Mundane example...  I have two users  Dick and Jane.  If did is on the
> system as the 'console' user can i have a specific device mounted
> readonly under the mountpoint /media/Dick's Drive and when Jane is
> console user have the specific device be mounted read-write under
> mount point /media/Jane's Drive.
> 
> Is hal policy flexible enough to deal with different users in
> different ways? Or to create a mount point based not just on device
> information but on 'console user' information as well?  I realize that
> the default hal policy tries to target the most common single user
> needs... but once you start considering multi-users systems local
> admins might want to create policy that works differently depending on
> who is logged in at the console.
> 

No, this is not currently possible. I think the direction we should
take involves killing fstab-sync and moving to using mount wrappers
much like pmount that Ubuntu uses. E.g. the desktop stack would call
hmount-gtk (KDE could use hmount-qt) to do the mounting and said
programs would read both HAL policy as well as the users setting
from e.g. gconf. Patching GNOME to do this is easy; one just needs
small patches for gnome-vfs and gnome-volume-manager. IIRC Ubuntu
does this.

 1. We can have per-user policy and build the UI to modify it, e.g.
    it would be easy to extend the Nautilus property page for a
    volume with options "Select mount point", "Optimize for fast
    removal (options sync, noatime)" or "Optimize for performance".
    This would be per-user.

 2. We wouldn't touch /etc/fstab at all which is good for so many
    obvious reasons

 3. Mount points for optical discs (and other volumes not using
    partitioned media) would be more sane. E.g. if today the
    mount point for my FC3 install media is /media/cdrecorder;
    it would be more natural using the volume label e.g.
    /media/FC3\ i386\ disc3

 4. The mount wrapper could interact with the desktop and ask
    the user for the root password if the system is configured
    to not allow the user to mount removable and hotpluggable
    media by default (would be an install option). Even though
    this sounds like an useless example, keep this article in
    mind (look for the paragraph mentioning epoxy glue):

     http://www.pbs.org/cringely/pulpit/pulpit20040916.html

    Actually, some time ago, someone proposed this to me:

    Click
        "You must be root to mount the volume 'Dave's USB key'"
    [grr]
        Password
        Would you also like to automatically allow
        - This user to mount Dave's USB key
        - Any user to mount Dave's USB key
        - This user to mount a USB device
        - Any user to mount a USB device
    [happy]

Personally, I think 1, 2 and 3 is nice. 4 might be nice as well
although I think we generally want to move in a direction where
we don't ask the user for the root password.

Sure, there will be proponents of ditching fstab-sync, people
will scream "oh, so how do you expect I mount by cdrom from the
command line, gimme back my /etc/fstab line for /dev/cdrom", 
but personally, I think the trade off of improved desktop UI
versus command line users is worth that. Command line users
probably know how to an entry themselves, otherwise they
wouldn't be using the command line in the first place :-)

I don't run this show though, so it's still an open question
if we should move away from fstab-sync :-)

Cheers,
David