Roland Mainz writes: > James Carlson wrote: > > ... then we'd have a security problem, and merely invoking rksh > > (without creating a whole new /usr/rbin world) would not resolve the > > problem. > > That is IMO not a problem since you (usually) _never_ run a shell in > restricted mode without a "custom" PATH which only has no or only a > restricted set of binaries available
You've effectively just repeated what I said: the developer invoking this feature would have to create a /usr/rbin world to limit the scope of the possible damage from malformed strings. I think that's an absurd level of complexity for a relatively simple feature. The much more obvious alternative is to make this new function use varargs or an array for argv, so that no argument cracking at all is required. In all of the cases I've examined in the existing code (for which the proposed function would be viable), such a replacement function would work fine. > An example would be an internet facing server deamon like an in.httpd > written in ksh93 (or the IRC bot demo in ksh93-integration update1) - > you would switch to "restricted" shell mode to improve security and > doesn't want to see it compromised by allowing the restricted shell to > execute /usr/bin/sh. A similar issue exists with RBAC - in theory you > could allow people to "pfexec" a normal, unrestricted shell... but > doesn't make sense from a security point of view. For the same reason it > doesn't make sense to run a "restricted" (sub-)shell ([1]) without > changing PATH first. I think that's very far afield of the original proposal. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
