Interactions between POSIX.1e privileges and "user mounts"

Robert Watson rwatson at FreeBSD.org
Tue Dec 16 21:35:29 GMT 2003


This is more of a "what makes sense" and "by convention" question that
occurs in the context of user mountpoints: i.e., the ability for an
unprivileged user to mount and unmount selected file systems.

In FreeBSD, a global system configuration toggle (set using a sysctl) 
permits users to mount file systems from devices they have appropriate
read/write privileges on to a directory they own.  This defaults to off as
there are some fairly nasty implications, but it's also convenient
functionality to turn on on some workstations.

This appears to conflict, semantically, with the notion of an unprivileged
root user.  When usermounts are enabled, you see access checks like the
following:

                /*
                 * Only root, or the user that did the original mount is
                 * permitted to update it.
                 */
                if (mp->mnt_cred->cr_uid != td->td_ucred->cr_uid) {
                        error = suser(td);
                        if (error) {
                                vput(vp);
                                return (error);
                        }
                }

With a move to capabilities in one of our development trees, it becomes:

                /*
                 * Only root, or the user that did the original mount is
                 * permitted to update it.
                 * XXXMAC: Should be VADMIN?
                 */
                if (mp->mnt_cred->cr_uid != td->td_ucred->cr_uid) {
                        error = cap_check(td, CAP_SYS_ADMIN);
                        if (error) {
                                vput(vp);
                                return (error);
                        }
                }

Which is based on the Linux extension to the POSIX.1e capability set,
CAP_SYS_ADMIN, which is basically a "catch-all" for any privileges left
over that aren't well described by another privilege, and generally refers
to administrative privileges.  The problem is this: if you run a system
with POSIX.1e privileges, you are generally doing this for two reasons--to
differentiate privilege from the root user, or to permit granting of
privilege to non-root users.  If usermounts are enabled, the root user can
mount file systems both "with privilege" and "without privilege".  The
root user might also later try to update or unmount a mountpoint earlier
mounted as one or both of these.  Should an unprivileged root user be able
to mount/update a file system mounted by a privileged root user?

The first two answers to pop into my head were:

(1) Yes.  If the administrator enables usermounts, and there's not another
    policy (such as MAC) that prohibits the operation, the root user
    should be able to unmount a file systems it "owns".

(2) No.  We should track whether a file system was mounted with privilege,
    and only permit update/unmount with privilege, or some of the inherit
    tie-in with integrity models will break down.

Since privilege systems like POSIX.1e privileges are fairly incomplete
unless you tie in an integrity model anyway, (1) is certainly a simpler
answer.  However, if you assume the system might want more fine-grained
privileges and is running without a Biba-like integrity model, you really
need (2).

I was wondering if any other systems existed that deployed a usermount
model similar to this (rather than using an automounter running with
privilege), and that had addressed this particular situation one way or
the other.  Likewise, there's a similar problem with file systems mounted
"with privilege" by another user, and whether they should be unmounted... 

Thanks,

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research



To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message



More information about the posix1e mailing list