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