Subject: Re: Dividing securelevel implications to kauth(9) scopes
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Elad Efrat <elad@NetBSD.org>
List: tech-kern
Date: 05/16/2006 20:38:37
YAMAMOTO Takashi wrote:
> i think chflags shouldn't be "generic".
"vnode"?
> 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.
The above is similar (just change the securelevel being conditionalized)
for all securelevel references in sys/dev *except*
wscons/wsdisplay_compat_usl.c:
int
wsdisplay_usl_ioctl2(struct wsdisplay_softc *sc, struct wsscreen
*scr, u_long cmd, caddr_t data, int flag, struct lwp
*l)
{
[...]
switch (cmd) {
[...]
case KDENABIO:
if (kauth_authorize_generic(p->p_cred,
KAUTH_GENERIC_ISSUSER, &p->p_acflag) ||
securelevel > 1)
return (EPERM);
[...]
Where the check could be refactored to one authorization request where
the listener would look into both the credentials and the securelevel.
So, the driver scope -- as of now, anyway -- doesn't care about the
request context, so there would be no arguments passed to the
authorization wrappers.
Does this answer your question?
-e.
--
Elad Efrat