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 for (3) is there a user level diagnostic? special exit code? what happens for (4)? --Glenn On Wed, 17 Mar 2010 14:06:33 +0100 Casper.Dik at Sun.COM wrote: > > > >On Wed, 17 Mar 2010 09:27:00 +0100 Casper.Dik at Sun.COM wrote: > >> > > >> >we're looking into a 1 line fix for this > > > >> Note that we're also moving "pfexec" inside the kernel; so there's no > >> additional "pfexec" command needed and for all other shells can then run > >> without support for profile shells. ksh93 will still need support for a > >> profile shell but only to make sure that it doesn't run the internal > >> commands. > > > >I don't know pfexec details, so any or all of these may be nonsense: > > > >is pfexec inside the kernel vs. /usr/bin/pfexec be (run/compile)-time > >detectable? > Compile time (that is, if you compile against the header files of the > kernel you want to run the binary on which is normal for OpenSolaris; > also runtime as long as you compile with the newer headers because you need > specific flags to be used in a system call) > >can an inside-the-kernel but still pfexec'd process detect that it is in > >pfexec mode? > Yes. > >ksh93 has a call to exec_attr() as a final check for prefixing a command > >with /usr/bin/pfexec > >we intended to use that to augment the builtin/plugin vs. a.out check for > >pfexec > >(i.e., if mkdir is not active via exec_attr() then the builtin/plugin is ok > >to use) > >will a user level exec_attr() still be in play for the inside-the-kernel > >pfexec? > Yes. > >would it be possible to have user level calls that assert > > pretend I'm running the foo command now until ... > > stop pretending I'm running the foo command > >so an application could optimize out fork/exec and still play nice with > >pfexec? > Yes, actually it could. > Note that a missing of an "exec attr" in that case may means that you are > *not* allowed to run the command. The default profile will contain a > "wild card" for all commands: > All:suser:cmd:::*: > I believe, but will need to verify that, that in such cases the exec->attr > is NULL and it that case and only in that case you can run the internal > command. > Casper
