Roland Mainz wrote: > Darren J Moffat wrote: >> Roland Mainz wrote: >>>> Darren J Moffat wrote: >>>>> I did agree (and put it in email) that ksh93 is actually better in this >>>>> case since there is a way to turn off the builtins. Where I don't agree >>>>> is that the writer of the script should have to know to do that when >>>>> ksh93 is operating as pfksh93. >>>> I was thinking of a policy file in /etc/pfksh_profile which could be >>>> read prior to the processing of the main script, when run by the pfksh. >>>> Builtins could be disabled explicitly. >>>> Not sure if I want Yet Another Magic Filename like /etc/suid_profile. >>> Maybe a better name would be /etc/ksh.rbacrc to be consistent (at least >>> with /etc/ksh.kshrc for interactive shells). The tricky part is then >>> that I would expect that a shell should be allowed to switch to "profile >>> shell mode" and back dynamically. If this is not the case then >>> /etc/ksh.rbacrc may work... >> There is no functionality in any of the pf*sh implementations today to >> switch between RBAC profile mode and non profile mode. If a user needs >> to distinguish between using the privileges they are given by RBAC and >> not then they are NOT candidates for using a pf*sh; instead they should >> use what ever normal shell they like and use pfexec when they want to >> run the commands with the privilege RBAC gives them. >> >> Making it dynamic makes this much more complex than it really needs to be. > > ... but I can imagine cases where it may be desireable to switch between > both modes, for example a larger application based on dtksh (assuming it > is based on our ksh93 work) where parts of the application should run in > a non-priviledged mode and other parts should make use of RBAC profiles.
I can imagine that too however that is not the architecture of reference for the profile shells in Solaris. If you want to change the architecture of how the profile shells work then I would like it to be done for all of them at the same time rather than having something that is ksh93 specific. There may very well be cases were you don't want the end user to have the ability to choose if RBAC profiles are active or not. This means we have a per host and per user policy control to deal with. That means you need a way to manage that policy and set it. As you can probably see this starts to become quite a non trivial project addition. I would highly recommend not attempting to tackle this at least until we have heard from Casper on how he proposes to do away with the need for RBAC modifications to the shells. > Another quite problematic issue are "includes" - how should a shell > function loaded from a shell function "library" (where "library" doesn't > mean the *.so stuff, I am more thinking about something like C-style > #include here, shell code which gets "source"'ed or "autoload"'ed) > figure out that it should not use the builtins during execution time (or > better: The authors of such a shell function "library" likely do not > know about the RBAC issue here - they simply write the shell function > "library" and expect that it executes properly regardless in wbich mode > the shell is. Changing the default behaviour would break such shell > function libraries in a quite unpredictable way...) ? I don't understand how this would break, could you give me an example so I can see what you believe gets broken. -- Darren J Moffat
