>
>looks like I'm on a roll
>the "pretend" bracketing for builtins/plugins should be useful
>it will be interesting to compare the overhead of "pretend" vs. fork+exec
>
>if you provide code snippets for the "Yes"'s below we can merge them into
>the ksh src and provide a draft implementation for testing
>
>variants for /usr/bin/pfexec vs. inside-the-kernel would be good
>
>so the exec_attr test has these possible results (maybe more?)
>(1) run no-pfexec
>(2) run pfexec
>(3) don't run
>(4) failure of call
We call getexecattr and the outcome is:
NULL (you are not allowed to execute)
exec returns non-NULL but with attr == NULL, execute w/o pfexec
exec returns a non-NULL attr: execute w/ pfexec
Call to determine whether:
in-kernel pfexec exists
this is a profile shell:
#include <priv.h>
#ifdef PRIV_PFEXEC
uint_t val = getpflags(PRIV_PFEXEC);
if (val == (uint_t) -1)
/* Compiled in, but not supported by the kernel */
else if (val == 0)
/* Not a profile shell */
else
/* It's a profile shell */
#else
/* Use the old "call pfexec" */
#endif
When execve is denied by in-kernel exec, execve returns EACCES.
>for (3) is there a user level diagnostic? special exit code?
>
>what happens for (4)?
Failure of what? getexecattr()?
Casper
