Roland Mainz wrote: > Joerg Schilling wrote: >> James Carlson <james.d.carlson at Sun.COM> wrote: >>> It can't be in libcmd, because those external programs themselves will >>> link to libcmd to get the implementation there. You'd just recurse >>> forever. >>> >>> In order for this to work, either (A) all applications using libcmd >>> must become smart enough to know when to do exec() instead or (B) no >>> application other than a /usr/bin/* utility implemented by way of >>> libcmd should ever link against libcmd. >> If ksh93 likes to provide commands that behave like the builtins, the only >> way I see is that ksh93 checks whether a specfic command needs special >> treatement and then calls /usr/bin/pfexec /usr/ast/bin/<cmd>. >> >> Then the database in /etc/security needs to be enhanced for >> /usr/ast/bin/<cmd>. > > Or we create a new sibling of "pfexec" (for eaxmple called "pfkshexec") > which executes the commands in a new ksh93 instance after the RBAC > context has been established... would that work ?
It could in theory work but why ? You do realise that pfexec(1) is setuid root right ? What is the objection to having pfksh93 use pfexec to execute /usr/bin/chmod rather than the ksh93 builtin chmod ? If I can understand that maybe I can understand why you seem to want to do this differently for ksh93 than how it is done today for pfsh, pfcsh and the exising ksh88 derived pfksh (and how the pfzsh that I haven't shipped yet works too). -- Darren J Moffat
