> > i think chflags shouldn't be "generic".
> 
> "vnode"?

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.

YAMAMOTO Takashi