YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>>> I don't see
>>>> any case where this would matter, in practice.
>>> i think a listener might want to know the original request,
>>> if it does some kind of logging.
>>>
>>> YAMAMOTO Takashi
>> yeah that's the obvious case, but I think that's something we'll just
>> have to live with. :)
> 
> i disagree.
> if we want to introduce the order of listeners, we should introduce
> a way to control it as well.

it has come up in the past. I don't want to do that.

>> let's put it another way: bsd44 secmodel says "silently enforce nosuid
>> and nodev, as if the original request had them". so logging "non-root
>> user wanted to mount /foo on /bar with no flags" or "with nosuid, nodev
>> flags", as far as bsd44 secmodel, is the same.
> 
> are you serious?

yes. these are the current semantics. a different model may strictly
deny mounts for non-root users, or just deny them altogether if they
don't contain nodev/nosuid. (it would always check "only allow non-root
mounts if dovfsusermount==1 and no privileged options were requested".)

the problem here is that the semantics are just ugly. we could approach
it differently: before we respect suid/dev (in kern_exec.c and
spec_vnops.c - is that enough?) we could issue a KAUTH_SYSTEM_MOUNT_PRIV
with the desired option. then the mount would not say it's nodev/nosuid,
but would still ignore them.

I don't have a better solution atm.

>> other cases.. well, "when the time comes". :) (we're already past 4.0
>> branch so we have time to change in the future if there's need.)
> 
> i don't understand what you mean here.

"other cases" = other security models, and I addressed that above. but
because there's no rush and this isn't for 4.0, we're not obliged to
keep anything we do. we're also not obliged to solve it now, but I'd
really like to get the securelevel bits out of the day...

-e.