Subject: Re: usermount semantics changed... Why?
To: Peter Seebach <>
From: Bill Stouder-Studenmund <>
List: current-users
Date: 06/27/2007 12:00:58
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 10, 2007 at 12:45:36PM -0500, Peter Seebach wrote:
> In message <>, Antti Kantee writes:
> >That snipped looks like it requires MNT_NOEXEC only if you are mounting =
> >a file system which already has MNT_NOEXEC set in vp->v_mount->mnt_flags.
> >noexec is not generally required for user mounts.  My guess is it's to
> >prevent the user gaining access to an exec-worthy file system in case
> >e.g. /home is noexec.
> Oh, good point.
> Nonetheless, it is certainly a change that this is now enforced by kauth,
> rather than being silently added by the syscall.

It is.

As Elad was noting, the best thing to do is change either mount(8) or=20
mount(2) to do this. I'd tend to say mount(8).

When we started w/ kauth, we actually had this still working as it is now.=
The problem is we have to let kauth authorizers be able to add mount=20
flags. Well, we didn't come up with a way to ensure that said routines=20
couldn't REMOVE flags. So you could make an authorizer that made all=20
mounts never have the nosetid and nodev flags! That'd be bad.

In retrospect, we could have rigged it up so that an authorizer could add=
flags and the caller actually adds them in, thus making it imposible for=20
an authorizer to remove flags. i.e. "I'll aprove this operation if you add=
these flags to it." That however 1) complicates the security interface,=20
which is supposed to really just say yes or no, and 2) we technically=20
might want to restart the autorization sequence as the flags are=20
different; later calls are seeing a different request than the initial=20
ones do.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)