Re: More KAUTH_GENERIC_ISSUSER replacements

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On Tue, Apr 28, 2009 at 3:24 AM, YAMAMOTO Takashi
> <yamt%mwd.biglobe.ne.jp@localhost> wrote:
>> hi,
>>
>>> Hi,
>>>
>>> I would like to introduce the following actions/requests as alternatives
>>> to some KAUTH_GENERIC_ISSUSER uses:
>>>
>>>   - KAUTH_SYSTEM_MOUNT::KAUTH_REQ_SYSTEM_MOUNT_UMAP: special request for
>>>     mounting a umapfs. See miscfs/umapfs/umap_vfsops.c.
>>
>> isn't it better to make KAUTH_REQ_SYSTEM_MOUNT_NEW take the filesystem type?
> 
> If we add the file-system name, it means we're expecting security
> models to check for a specific file-system name (or names) and just
> "know" that it allows one feature or another.
> I would rather we ask the security model, "can these credentials be
> used to mount a file-system that allows user mapping?".

then, "mounting a umapfs." is not a good description. :)

> 
> (Future thoughts: there's a GSoC project this year that might result
> in the ability to query file-systems about their features. I'd like to
> see how that goes, and perhaps look into passing more data to
> listeners in immutable proplib dictionaries. This might buy us the
> ability to say "the secmodel can check for the following keys..." and
> solves an issue where a listener can modify data and thus affect other
> listeners. But that's irrelevant for the moment and shouldn't prevent
> us from implementing even a "temporary" solution.)
> 
>> if you want a check for changing credentials,
>> it doesn't really belong to KAUTH_SYSTEM_MOUNT, i guess.
> 
> Good point, as it's possible to leverage this ability to create a root
> process. :)
> 
> I don't have a good answer. What we can do (and I plan to, regardless
> of this specific issue) is document the possible implications of each
> kauth(9) action/request. If we do end up adding a specific request for
> mapping users, we can mention it can be leveraged to grant credential
> change as well. That said, you need to remember that kauth(9) is not
> the layer that is to be exposed to the user: that is, if we introduce,
> say, a "privileges" or "capabilities" interface, we can combine the
> two together into one capability; kauth(9) will just ask the secmodel
> a more "specific" question. :)

i'm not sure what you mean here.
are you suggesting to have KAUTH_FOOBAR_UMAP for every possible FOOBAR?

> 
>>>   - KAUTH_SYSTEM_RESOURCE_RESERVEDSPACE: action for checking whether the
>>>     reserved space allocated on the file-system can be used. See
>>>       ufs/ext2fs/ext2fs_alloc.c and ufs/ffs/ffs_alloc.c.
>>>
>>>   - KAUTH_SYSTEM_RESOURCE_QUOTA::KAUTH_REQ_SYSTEM_RESOURCE_QUOTA_ with
>>>     NOLIMIT (check if the quota limit can be bypassed), GET (for reading
>>>       quota information), and MANAGE (check whether the caller can manage
>>>       quota by enabling/disabling it and setting quota for users). See
>>>       ufs/ufs/ufs_quota.c and ufs/ufs/ufs_vfsops.c.
>>
>> these should be named to imply that they are filesystem-related.
>> sorry, no good name from me. :)
> 
> How about we replace RESOURCE with FS?

it sounds better to me.

YAMAMOTO Takashi

> 
> Thanks,
> 
> -e.