Glenn Fowler writes:
> > In order for this to work, either (A) all applications using libcmd
> > must become smart enough to know when to do exec() instead or (B) no
> > application other than a /usr/bin/* utility implemented by way of
> > libcmd should ever link against libcmd.
>
> does this mean that the sh implementation makes some kind of contract
> on what system calls it will make? e.g., if chmod(1) requires pfexec,
> then can the sh implementation make a call to chmod(2) under any
> circumstances?
No, not quite.
If the assertion is that linking to libcmd and calling the functions
there is "just like" fork/exec of those same things, then the caller
(today) needs to understand when to exec the 'pfexec' setuid utility
instead. In the future, when exec is (with some hope) made more
natural, the caller will need to know when the libcmd function is
"just like" fork/exec and when it's just not.
There's no limitation on the use of chmod(2), though. If an
application calls that, and it needs additional privileges or a
different uid, then the entire program needs the additional
privileges. It's not expected that invoking chmod(2) causes you to
get new privileges.
That's the problem. If the user sets $SHELL correctly to a pf-type
shell and configures RBAC as needed, then any shell-invoked uses of
chmod(1) should get RBAC-controlled behavior. The surprising effect
here is that there are cases where (for ksh93) it doesn't, and where
innocent recoding of 'system("chmod ...");' results in different
behavior (and perhaps actual failure).
--
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
