Subject: Re: usermount semantics changed... Why?
To: Martin Husemann <email@example.com>
From: Elad Efrat <firstname.lastname@example.org>
Date: 06/10/2007 20:45:33
Martin Husemann wrote:
> On Sun, Jun 10, 2007 at 11:39:17AM -0500, Peter Seebach wrote:
>> On my system, at least, it's not that they're the default -- it's that
>> they're *not* the default, but without them, mount fails with EPERM.
> Yes, I think this has been discussed quite some time ago on tech-kern.
> When cleaning up the security related stuff and centralizing it in the
> secmodel, there was no good way to pass such blatant layering violations
> through to the secmodel via kauth.
> Maybe, but I'm not sure about it, we should handle it in userland (i.e.
> modify mount(8) to either print a helpful error message or to auto-add
> the needed options.
indeed it was discussed months ago. mount(8) does have information:
(looking back, perhaps a note about noexec should be added. :)
the original design was flawed. the kernel should not silently enforce
anything, and the new code works by allowing what is allowed and denying
what is not allowed. technically it's ~impossible to implement the
original semantics, too, because of the way kauth (and any other
framework, for that matter) works: originally the privileged operation
was checked in one place, allowing modification of the input data. with
kauth, there is a potential for more than one listener checking the
data, and allowing a listener to modify it means presenting bogus data
to the rest.
at the time, we did discuss shifting the handing to userland, where it
belongs, but the code to silently handle it was not written yet.
basically, it would be something like:
...of course you can query for noexec and add it if it's present, etc.,
but that's the idea.
note, that on a hypothetical system that supports process privileges,
one could simply query the present privileges (think 'P' set) to know if
these flags should be set or not:
if dont have privs for nodev/nosuid
if noexec present