On Tue, Mar 16, 2010 at 6:04 PM, <Casper.Dik at sun.com> wrote: > > I filed the following bug: > > 6934527 pfksh93 does not work for builtin commands
This bug might be a candidate for a WONTFIX. The root cause is that the pfexec *design* is utterly broken (giving a whole process extra privileges, ignoring the fact that part of this process may be compromised. The granulation is the wrong one and should never grant a whole process such a power) and deliberately ignored the concept of shell builtins in POSIX shells. Sure, Sun never cared much about POSIX when designing own APIs but we have again the case where this ignorance in the design process strikes back. > > pfexec is only executed for "external" commands and not for > internal commands. This is the correct behaviour. Commands which require special privileges should intentionally be marked as privileged, in this case by specifying the full path of the command (which prevents the shell from using a builtin command). > ksh93 has implemented quite a few commands > as internal commands and programs such as "mkdir" are no longer > run with the appropriate privileges. > > I want to change ksh93 that when it runs as a "profile shell", it > needs to disable all builtin commands listed in "cmdlist.h"; This would cause "7000000 Putback for 6934527 regressed pfksh93 performance, scripts run 70-100 times slower". AFAIK this kind of performance regression is a no-go in ON, right? Shell builtins were always there (echo, printf being the most popular pre-POSIX incarnations) and just ignoring or disabling them will only cause *more* trouble, usually by breaking scripts in subtle ways. Either the pfexec design needs fixing or script authors must clearly use the full path of commands which require extra privileges. > I understand that they are all registered with the full pathnames. > In inittree() and want to ignore all such pathnames for the > shtab_builtins. Or is there a better we to avoid these builtin > commands? > > This, of course, is in OpenSolaris a problem also for sh and ksh as > they're all "ksh93". I think the problem is the design of pfexec and friends which should be fixed and not that the broken policy enforced upon ksh93. It will just break things, including scripts which rely on features only present in the builtin command and not in the /usr/bin commands, signal handling and other stuff. Irek
