Re: [Utopia] Re: Removable devices and fstab

[Nathaniel McCallum <npmccallum gentoo org>]

On Mon, 2004-08-30 at 22:16 +0200, David Zeuthen wrote:
> 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?

Tell me how you would suggest implimenting a policy for device types or
unique device ids.

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

The point is that device names are not tied to specific hardware, which
makes for bad policy decisions (which makes for security holes).

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

You're missing my point.  fstab-update *is* a security hole.  It would
certainly never pass government certification for use in a secure
environment.  When inserting a removeable device automatically changes
your mounting policy file, you have a security hole.  The policy file
should *never* change unless you want it to. Therefore, the policy file
needs to be more intelligent to handle devices it doesn't exclusivly
know about.  Then you never need to change the policy file.

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

Of course hal does.  I'm talking about making fstab/mount/etc use them
as well.  I'm *not* talking about changes to hal.

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

Again, I'm not suggesting making changes to hal.  I'm talking about re-
inventing the fstab wheel so its more intelligent.  And can handle
devices with both more ambiguity (ie. device types) and specificity (ie.
uid's)

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

I don't disagree.  But fstab is currently too stupid to know how to
handle modern hardware or modern security.

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

Which is why I'm saying skip both pmount and fstab sync and lets do this
upstream in fstab.

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

Yes, hal is great.  It needs to be used more.  But at the same time,
UNIX conventions (for example fstab) are not ready for the modern
hardware paradigm.

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

This is exactly my point.  We now have 2 policy files *and* a program to
modify one policy file against the other *and* a program to mount
(mount).  pmount has only one policy file and 2 programs to mount
(pmount and mount).  In that sense we are one up on fstab-sync.  What
I'm suggesting is to improve fstab and have one policy file and one
mount program (mount).  No other tricky magic.

Nathaniel