[indiana-discuss] scope

[Keith Bierman]

On Aug 8, 2007, at 2:39 PM, Eric Boutilier wrote:

>
>
> Keith -- I for one would love it if you could enlarge on this a bit.
> (Even though I know what all the individual functions and technologies
> are in paragraph above, I'm still having a hard time wrapping my brain
> around the overall mechanism/environment you're describing -- and I'm
> guessing I'm not the only one...)
>

Well, I can't sketch out the answer, because I don't actually get the  
RBAC stuff myself enough (it's on my list of things to work on  
mastering someday, but it's a long list). It's more of a "I think we  
have the plumbing, but I'm not sure of where all the parts are in the  
storage shed" kinda rant.

I think we can all agree that sudo is deeply ingrained into a huge  
number of linux (and mac) users. It's probably a little less 100%  
that everyone would agree that isn't a good thing on a large  
enterprise box, but probably close on this list ;>

I want to exploit the previously trained fingers that want to do some  
administrative action and type "sudo" and have it be something more  
in keeping with the rich featureset of Solaris. We aren't going to  
retrain their fingers on day 1 or 2, they need to have a smooth  
experience at first.

Since the vast majority of "developer desktops" are either single  
user or very small number of users, I would want us to have an  
appropriate profile (I think one already exists, but I could be wrong  
since my brief experiments haven't worked yet) so that we could  
hijack "sudo foo-script" into actually being something that leveraged  
RBAC (and the default install for Indiana and perhaps SXDE would be  
slightly insecure in that the first user defined would be special and  
have the appropriate administrative priv by default. We mostly do  
that now in SXDE, but we call that account root and make the user  
create a user account. That is, I think, backwards from the Mac and  
Linux (at least some Linux) experience where one creates the user,  
and the user has sudo rights).

Assuming that something like "pfksh fooscript" (or perhaps it needs  
some options baked in) could gain the same effect as sudo for the  
vast majority of operations, then I'd suggest we ship the default  
bash_profile and ksh_profiles to define a shell function "sudo" which  
would expand to the be suitable pfksh $args).

No doubt some people will insist on having real sudo, and I certainly  
wouldn't object to it being available (unless during installation  
someone selected the "I want a secure system" option ;>). But I'd bet  
that we could get a lot of leverage out of hijacking their fingers to  
do something "better".

I think of this as merely illustrative of what I think the basic  
thrust should be; 99.9% the "expected" CLI input from the experienced  
linux user ... but it doesn't have to be plumbed the same way.

It should be "easy" for a purist to escape from our helpful embrace.  
Whether that's done via the useradmin functions or via a zone or some  
other mechanism, I defer to those more skilled than I.

As for the future, I think that as much as folks want a single long  
train, that the imperatives are different enough that clever ways to  
split the difference (e.g. branded zones) are the way to go.

Those applications which exist need to run 'forever'. But we must not  
make the visible burden of compatibility seem so obvious to the  
consumer. The recent /usr/gnu solution notwithstanding, there will be  
things which can't be easily split (and just because we've figured  
out how to do it now, we'll have the same fundamental issue at some  
future time ... just as we did with bsd vs. sysV ... unless  
OpenSolaris manages to overtake all other OS's into the indefinite  
future. Possible, but not an approach to count on).

Things like libraries need to be crafted carefully, we certainly  
wouldn't want each zone to become an island as separated as different  
real systems are. But I could easily imagine that one way to allow  
for very fast progress on the linux adoption front would be to bite  
the bullet, specify it as a separate zone and let it evolve as fast  
and furious as it can. As fast as "Solaris Classic" can adopt things,  
and as much as it can, those innovations go into the Solaris Classic  
zone(s).

Project Indiana releases would default to having just the "Indiana"  
zone. Solaris.Next would default to having a Solaris.Next and Indiana  
zone (if need be, a Solaris.Classic; but our usual ARC evolution  
would negate the need for that ... although it might well make  
getting ISV certification a lower barrier than new Solaris releases  
are today).

In such a universe, we could just let the Linux lovers have /bin/sh  
be bash. It would reduce the number of script changes necessary for  
gaining ports. Application capture is the name of the game in gaining  
marketshare for a platform.

And while I like having the world evolve to having better, more  
portable code ... I'm reminded of the same attitude during the BSD- 
 >SysV kernel migration where we made dereferencing the null point a  
fatal error (where it had been silently allowed in most contexts  
under our BSD releases). The result was a ton of irritated users and  
ISVs and slower adoption of the new environment (having been in the  
compiler group in those days, and deeply involved with customer  
issues .. it was one of the most frequent complaints of the C  
consumers. That their code was broken didn't really concern them, it  
worked corrected on other platforms and previous versions of our  
platform ... so the changed behavior was highly irritating to the  
consumer/developer).

The lesson I learned from that experience is that developers don't  
really want their faces rubbed into their mistakes. They want their  
existing code to "just work" ... they may (and often do) appreciate  
tools that let them clean up their act in their own time ... but not  
ones which force their blunders to be obvious ... especially if the  
only discovery is at runtime (even at compile time, the most frequent  
requested compiler/lint options tend to be ways to suppress warnings  
and even errors!).
>

Keith H. Bierman    keith.bierman at Sun.COM   |  khbkhb at gmail.com
Strategic Engagement Team                   | AIM: kbiermank
<speaking for myself, not Sun*> Copyright 2007