Darren J Moffat wrote:
> Roland Mainz wrote:
> > However there are multiple workarounds (already described in other
> > postings here (e.g. use fully qualified path, an alias to the full path
> > etc.)) and AFAIK at least the following solutions:
> > 1. "pfksh93" checks whether there is a RBAC entry for the matching
> > command and disables the use of the builtin in this case (the problem is
> > that we "randomly" use either the builtin or the native OS version which
> > may or may not be predictable for the script author).
>
> You have already said you don't know much about RBAC. I do and I've
> answered lots and lots of questions on "why does my script not work".
> The two top issues that people hit are 1) Originally pfexec didn't
> follow symlinks, that is now fixed. 2) Clashes with shell builtins.
>
> From my experience I'd say that the author of a script that explicitly
> uses #!/usr/bin/pfksh rather than #!/usr/bin/ksh is expecting a
> different behaviour with respect to builtins.
>
> As far as the test suite for ksh93 is concerned I think that was a very
> good point to bring up. I don't believe you should expect that the test
> suite work 100% the same when run as ksh93 versus pfksh93.
I would expect that both shells behave exactly the same way unless there
are RBAC rules active which require a different behaviour. As I said in
another email here the POSIX shell specs explicitly allow and describe
builtins and somehow we need to find a way to get this working for RBAC,
too (one possible proposal would be to let the shell only execute the
builtin if there are no RBAC rules active for this command. The other
idea may be to execute a ksh93 instance through pfexec which then
executes the matching command (which would then run the builtin in the
propper RBAC context (this would be my preferred solution))).
> > 2. A new wrapper gets created ("pfkshexec", based on libshell which gets
> > called by ksh93 and copies-over the whole shell environment) which
> > executes the builtin command in the matching RBAC context
>
> > In general it would be my preference to avoid a "TCR" and let us develop
> > a propper solution in peace (without pressure), otherwise I fear we may
> > accidently "rush in" something which later turns-out to be a totally
> > useless monstrosity (note that we're initially putting back ksh93s-
> > alpha - which means we have much time left until ksh93s reaches the
> > "final" status...).
>
> So in ARC teminology that means you are droping pfksh93 from the
> specification of this case, and are telling the ARC that you are taking
> this offline with the OpenSolaris security community (I do hope you will
> talk to us rather than trying to do this on your own).
>
> Otherwise you are going to introduce pfksh93 with the current behaviour,
> which is different to the existing pfksh, and then possibly change it
> later. Thats not good and I don't see any value in doing that.
I disagree... see below...
> I
> believe this first phase project can be successful without introducing
> pfksh93.
Well, I hoped that it is somehow possible to have more than one ARC case
for the ksh93-integration, e.g. put this version back, collect user
feedback and then implement&&ARC the neccesary suggestions/changes...
which is now a little bit tricky since the profile shell is now excluded
from the case.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
