Updated case materials have been copied into the case directory
and are expected to be pushed out later today to
http://www.opensolaris.org/os/community/arc/caselog/2006/550
The updates include corresponding unified diff (diff -u) output
(in corresponding *-diffs files) against the originally-submitted materials.
Thanks,
April
A summary of the issues from the project team:
1) /sbin/*ksh93 on the root filesystem
The project team agrees to removing these binaries from the case.
Only one shell should reside on the root filesystem, which
is currently /sbin/sh. A future goal will be to replace Bourne shell,
/sbin/sh, with ksh93.
2) /lib/{libast*, libdll*, libshell*} on the root filesystem
The project team agrees to altering the case, such that the libdll and
libshell libraries and links will be delivered on /usr/lib only.
The existing /lib/libcmd.so.1 is already located on the root filesystem,
is currently used by applications that may require the ability to work with
only root filesystem access, and will have a dependency upon libast.
The libcmd dependency requires that libast also be placed in /lib.
3) pfksh93 is executing built-ins instead of binaries (e.g.,
the chown built-in instead of the /usr/bin/chown binary) and are
bypassing the RBAC process, which should allow a pfksh93 user to run
with altered privileges when executing commands specified by execution
profiles.
Although various proposals to disable some subset of built-ins from pfksh93
were discussed, the project team has agreed to remove pfksh93 from
the case, so the proper solution can be carefully considered, for
a future case.
4) There was a lengthy discussion concerning merging the existing
Solaris libcmd Sun Private interfaces and the new AT&T libcmd b_*()
built-in command interfaces (Project Private now, but the project team
expects that they will be made committed Committed Public in a future
case) into the same libcmd library.
The Solaris libcmd interfaces are widely used by many consolidations,
including unbundled products, so renaming the Solaris libcmd would
introduce an incompatibility that is difficult to resolve.
AT&T will not be renaming the library nor changing its location.
External applications will want to use the AT&T interfaces, so the
project team does not want to rename the AT&T libcmd on Solaris
systems. The project team will keep the new interfaces merged with the
old ones in the existing libcmd on /lib.
