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 [EMAIL PROTECTED] | [EMAIL PROTECTED] Strategic Engagement Team | AIM: kbiermank <speaking for myself, not Sun*> Copyright 2007 _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
