Quoth Gary Winiger on Wed, Jul 12, 2006 at 03:15:59PM -0700: > > The first draft of the Enhanced SMF Profiles design is now available at > > http://opensolaris.org/os/project/smf-profiles/Design . If you are so > > inclined, please review it and send feedback to this list. > > Smiles all around -- thanks. > Secure by default use case -- great. > > Open Questions: profile list in a name service > = is there a way to get this early enough in boot or
For the use cases I have in mind, I think it would be sufficient to change the profiles as soon as the name service was available, even if relatively late in boot. > to restrict what it can do after name services come up? I think setting the profile list from the name service more than once would probably be more confusing than useful. It might only make sense on first boot after install or upgrade, in fact. > Security: solaris.smf.modify seems too powerful to give out. > Perhaps a specific (action_authorization) authorization at the > service_bundle level that allows import/activation of a profile. > Perhaps also value_authorization to be able to dynamically change > what is there. The document proffers that unprivileged users be able to create profiles, as long as they can only set properties therein that they would be able to modify directly. I believe this allows for importation of profiles as well. Upon consideration, I believe profile activation is largely equivalent to mass property change. So authorization to activate should be the same as the highest authorization to change the profile properties. So I think activation may not necessary require all privileges, as the design stands. David
