On 02/12/10 02:11 PM, Dave Miner wrote: > As you may recall, we reviewed a first draft of this design in > December/early January. I've finally published a revision which > addresses the comments I received, primarily from Jan and Ethan. > > While not exactly frozen, implementation work is underway based on this > design so any remaining issues should be raised soon to allow the best > chance to address them. > > http://hub.opensolaris.org/bin/view/Project+caiman/AI+Image+Management
While not directly related, one thing I (and probably others) would find useful is discrete authorizations for certain actions. Right now, it seems to be a "you need to be root to do that or you can't do that at all" type of thing. One could assign installadm to a profile, and then grant that to users, but that now lets them do all installadm commands. As a recent example, letting users add manifests for their clients is something I'd be willing to let them do, but I don't want to let them run create-service or delete-service. I could imagine same is true for adding and deleting clients. So having some discrete authorizations here would be very handy. If we go back to legacy solaris, internally we had addclient, which was a setuid program that called add_install_client. This let users set up systems to boot, but wouldn't let them install/remove images, etc. With installadm, this could be solved by writing wrapper programs (installadm_manifest) which runs installadm with specific subcommands, but we have a good privilege/authorization model in solaris, so it would seem to make sense to use it. As an aside to that, if nothing else, there should just be a profile for installadm in exec_attr that could be assigned to users instead of making them become root.
