Roland Mainz writes:
> > (ie chown can't be a builtin when
> > running as pfksh93) and ideally that the code to do the pfexec execution
> > is implement in such away that it *always* executes the external
> > binary rather than the shell builtin if there is a profile entry for
> > that command for the euid of the shell.
> 
> IMO there is no need for such a change (and it would IMO very tricky to
> do it without blowing some existing ksh93 scripts up). There are at
> least three solutions for this problem:
> 1. Scripts can always load/enable/disable all builtin commands via the
> "builtin" command, e.g. "builtin -d chown" will remove the builtin
> "chown" and from this point the external command is used (you can use
> this in subshells, too (which only affects subshells)). This is part of
> the ksh93 language since a long time.
> 2. You can always specify the full path to the command (e.g.
> /usr/bin/chown) to execute the external command. The builtin commands
> are only used when you use the plain filename, e.g. "chown" which is
> then searched in ${PATH}.
> 3. You can combine [2] with "alias", e.g. "alias chown=/usr/bin/chown"
> will redict all calls of "chown" to "/usr/bin/chown", bypassing the
> builtin version of "chown" until the alias entry is undone.

I don't see how any of those are usable answers here.

The point of the "profile shell" is that the commands executed there
are automatically granted privileges according to what's configured
for the user.  The script writer doesn't need to know anything about
RBAC to make it work.

Having to work around it with 'builtin -d xxx' or other changes
defeats that capability.

Answers that seem useful to me are:

  - when invoked as pfksh93, the shell automatically disables all
    built-ins other than the intrinsically required ones (such as
    'cd').

  - when invoked as pfksh93, the shell becomes aware of RBAC and
    checks whether there's a profile for a given command before
    attempting to use the built-in; if there is, it execs the external
    version instead.

-- 
James Carlson, KISS Network                    <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to