Glenn Fowler wrote: > On Mon, 25 Sep 2006 11:44:16 +0100 Darren J Moffat wrote: >> 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 >> believe this first phase project can be successful without introducing >> pfksh93. > > dgk is offline today > but he is interested in getting pfexec right in ksh93 > the best way would be for someone to distil whatever reams of docs > pfexec implies into high level issues that outline sh(1)'s > pfexec responsibilities
Better than that I can point you to code! Sun's ksh88 may not be included on OpenSolaris.org but our /bin/sh code is! See: http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sh In there you will see two files sh_policy.h and sh_policy.c. These implement the way that a shell interacts with the RBAC databases and knows when to use pfexec(1) versus exec(2). There are changes to main.c to do the setup if we are called as pfsh and to service.c to call it. > was pfexec added to the sun /bin/ksh code? Yes it was. > if so then the diffs from non-pfexec-ized to pfexec-ized ksh > might be all that's needed to form the correct mapping onto ksh93 Except that ksh93 has more problems with builtins because there are more of them - which if you remember was my initial comment. What I pointed you to above should certainly be a good starting point. I would highly recommend not trying to address pfksh93 as part of this project but cover it when the project to do ksh93 as /usr/bin/ksh comes along. This gives you more time to deal with it and work with the OpenSolaris security community (myself and others) on the problem of ksh builtins. -- Darren J Moffat