Darren J Moffat schrieb: > Roland Mainz wrote: >> Joerg Schilling wrote:
>>> 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>. >> > 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). > I'm just an onlooker in this thread, but here's my impression: Apparently the ksh93 builtins don't have identical behavior to their /usr/bin/* counterparts. This may be mere extensions (e.g. additional options) or even slightly incompatible behavior. Authors of ksh93 scripts may rely on these behaviors, if they invoke these commands without a path or if they are explicitly using the ksh93 path binding mechanisms. So with ksh93 you can have: - a script invokes 'chmod' - the script relies an option or behavior of chmod that is only supported by the builtin chmod (libcmd.so:b_chmod), but not by /usr/bin/chmod. - ksh93 builtin handling rules cause the builtin chmod to be used. This way everything works fine, provided the ksh93 process has the necessary privileges that allow the chmod to succeed. Now if this same script is executed in a pfksh93 without the necessary privileges but with a profile that enables these privileges for /usr/bin/chmod, something breaks: - If pfksh93 uses the builtin, that will be executed without the privileges. - If pfksh93 invokes 'pfexec chmod' instead, the chmod invocation will have the necessary privileges, but won't understand the ksh93-specific extensions. AIU this can happen even if the script explicitly says '/bin/chmod', because ksh93 path mapping can map even that to a builtin. One way to fix this would be to place the ksh93 versions of the builtins into the file system (e.g. as /usr/ast/bin/chmod) and have pfksh93 pfexec that. Unfortunately that also requires all pertinent profiles to be updated to specify the /usr/ast/bin/* version as well, whenever it has one of the corresponding /usr/bin/* commands. A simpler fix that requires far more work would be to replace all the /usr/bin tools by AST-based equivalents, reconciling all the incompatibilities that may still exist on the way. Only then disabling the builtins actually works as it should. - J?rg
