> >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
