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?
can an inside-the-kernel but still pfexec'd process detect that it is in pfexec
mode?
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?
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?
