Subject: Re: Dividing securelevel implications to kauth(9) scopes
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 05/17/2006 18:21:49
> > i think chflags shouldn't be "generic".
yea, it sounds better.
> > can you propose operations and their arguments as well?
> > to me, it isn't clear how "driver" scope operations will be, for example.
> The arguments passed to the authorization wrappers are supposed to
> provide a context for the listener to make a decision. Every operation
> will have its own set of arguments.
> For example, we have the following code in sys/dev/tc/stic.c:
> static int
> sticopen(dev_t dev, int flag, int mode, struct lwp *l)
> struct stic_info *si;
> int s;
> if (securelevel > 0)
> return (EPERM);
> Where's it's clear we have no context needed to make a decision, so
> the arguments can all be NULL.
i don't think it's so obvious.
to define a kauth action, we need to figure out
why sticopen should be prohibited.
otherwise, we end up to have KAUTH_DRIVER_STICOPEN,
which is a poor choice, IMO.
besides, it can be done by listening more generic actions like "open".
in that case, you want to pass vnode pointer or dev_t, so that listener
can check if it's a "dangerous" device.