Re: More KAUTH_GENERIC_ISSUSER replacements

[Elad Efrat <elad%NetBSD.org@localhost>]

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?".

(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. :)

>>   - 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?

Thanks,

-e.