Subject: Re: usermount semantics changed... Why?
To: Peter Seebach <firstname.lastname@example.org>
From: Bill Stouder-Studenmund <email@example.com>
Date: 06/27/2007 12:00:58
Content-Type: text/plain; charset=us-ascii
On Sun, Jun 10, 2007 at 12:45:36PM -0500, Peter Seebach wrote:
> In message <20070610173456.GD18207@cs.hut.fi>, 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.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----