Re: [Utopia] Re: Removable devices and fstab

[David Zeuthen <david fubar dk>]

On Mon, 2004-08-30 at 15:38 -0400, Nathaniel McCallum wrote:
> I think mostly we are on the same page with what we want, but how to get
> there is the question.  I'm cc'ing the utopia list so others can join
> into this discussion.  
> 
> Perhaps the best thing is to provide a better fstab implimentation with
> backwards compatibility that could be used across all unix's.  If we
> wanted to do that, there are a few things to consider.
> 

Erhm, I'm not convinced that /etc/fstab is missing anything; what am I
not seeing? Why can't /etc/fstab be used as a placeholder for policy?

> What does /dev/sda4 mean?  Is it partition one on a zip drive?  Is it
> the fourth partition on a usb key?  Is it the fourth partition on a
> hardwired scsi disk?  My point here is that device names are entirely
> ambiguous.
> 

On Linux perhaps; go look at some proprietary UNIX systems (have
persistent device names); go look at udev (insanely configurable naming
policy); go look at the device_naming lists osdl org mailing list
archives for, uhm, discussion.

I say it really doesn't matter for desktop software[1] what the device
node is called - it's nothing more than a cookie just like major/minor
numbers is a cookie in the Linux 2.6 kernel. Remember, the point of hal
really is to avoid that desktop software developers care about
implementation details such as about device nodes.

(Of course you need the device nodes at the end of the day, but that
should be buried in higher level libraries)

> Here is a list of things I think we should be able to specify:
>    1. rules based on any device and/or filesystem attribute. For ex.:
>       a. filesystem uuid
>       b. filesystem volume name
>       c. unique hardware id of device
>       d. number of partitions (ie. device must have only one partition)
>       e. size of filesystem (ie. fs must be > 256MB)
>       f. device name (backwards compat)
>       g. device type (ie. usbkey, cdrom, memcard, etc)
>       h. filesystem type (ie. don't mount ntfs volumes)

These are all facts about storage devices and volumes, hal supports
these (and more); look at storage.* and volume.* properties.

>    2. mount point
>       a. static mount point (ie. /mnt/cdrom)
>       b. mount point pattern (ie. /mnt/USBKey[0-9]*)
> 

This is policy; remember hal enforces *zero policy* and that is
intentional (fstab-sync is an addon to hal, not part of hal proper).

However, policy can be maintained through callouts or in other ways like
pmount that you described. I just happen to think /etc/fstab is the way
to store this information; do you disagree?

You can of course also choose not to use fstab-sync and e.g. pmount that
you are advocating, however that breaks the tradition (for no good
reason IMHO) and causes software to break; suddenly sysadmins need to
learn to use something else than 'cat /etc/fstab' to discover policy
about storage. I'm leaning against this is not really an option for some
established vendors.

But as HAL doesn't enforce policy both things work; isn't this great?

> Rules should match the closest situation.  For instance, we should be
> able to say "(rule 1) let users mount cdroms except (rule 2) the cdrom
> with the uid of 12345" or "(rule 1) Users can't mount usbkeys, except
> (rule2) the usbkey with filesystem uuid 12345 and only by user johndoe".
>
> If we were able to specify policy in this maner we get the following
> advantages:
>    1. Clear separation of policy
>    2. No need for dynamic updating (ala fstab-update)
>    3. Consistancy of implimentation (everything is in fstab)
>    4. Backwards compatibility
>    5. Better security model
> 
> What are your thoughts?
> 

I think this is great, although I may tend to think that this is a bit
far fetched; I've probably missed something :-). 

What I think would be really great (ok, so I'm pushing it :-) is be a
patch against fstab-sync to read a configuration file with such policy
rules. Oh well, nuff said..

Cheers,
David

[1] : (Big iron) servers is another matter but that is for another
thread.