Tony, I did include the manifest in my last email :) http://opensolaris.org/jive/thread.jspa?threadID=118317&tstart=0 is the thread on opensolaris.org.
--Mike On Nov 20, 2009, at 5:07 PM, Tony Nguyen wrote: > Michael Corcoran wrote: >> Thanks for the help Alan, comments inline below. >> --Mike >> On Nov 20, 2009, at 1:52 AM, Alan Maguire wrote: >>> hi Mike >>> >>> Michael E. Corcoran wrote: >>>> Hi All, >>>> >>>> I'm working on a project where we have a new daemon that we want >>>> controlled by smf to support a specific hardware feature for a >>>> given platform. What we'd like would be to have this daemon >>>> start automatically and thus have it enabled by default, but this >>>> goes against the info at >>>> http://hub.opensolaris.org/bin/view/Community+Group+arc/SMF-policy >>>> >>>> "Services must be delivered (by manifest or programatically) >>>> disabled by default to align with Sun's security goals. Projects >>>> impacted by Appendix C, must consult with the ARC to determine if >>>> this aspect of the policy is applicable." >>>> >>>> >>> The usual approach here is to have the service disabled by default >>> in >>> the manifest but to specify that it is to be enabled in one of the >>> profiles >>> specified in /var/svc/profile. >> Great. this makes sense. >>> These consist of customizations that are >>> activated in particular scenarios. You'd want to add >>> >>> <service name='mysvc' version='1' type='service'> >>> <instance name='default' enabled='true'/> >>> </service> >>> >>> The question is which profile to add this to - there are platform- >>> specific >>> profiles already, see usr/src/cmd/svc/profile in the ON gate for >>> examples. You probably want to add it to one of these. >> So how do these profiles get activated on a specific machine? It >> looks like we'll have to make a platform_i86pc.xml since none >> currently exists. > > On every boot, system/manifest-import applies a couple of system > profiles, platform is one of these profiles. For specifics, see > section 3 of /lib/svc/method/manifest-import. For x86 machines, the > current platform profile is a symlink to platform_none.xml thus a > new platform_i86pc.xml for x86 machine is reasonable. > >>> >>>> Our plan was to have it enabled by default on all x86 platforms >>>> and then have it exit and disable itself if it determines that >>>> hardware does not support this specific feature. So I'm assuming >>>> we need to go to PSARC to figure out if this approach is >>>> acceptable or is there a different ARC we'd be going to? >>>> >>>> >>>> I'm also unclear about >>>> "Services must include an appropriate RBAC profile and set of >>>> authorizations for manipulating the service and its specific >>>> configuration." >>>> >>>> If our service has no configuration, then I think we don't need >>>> the above. Is that correct? >>>> >>>> >>> There's two parts to this - manipulations of state and manipulations >>> of configuration. You'd probably want an solaris.smf.manage profile >>> which specifies auths needed to change state (i.e. to enable/ >>> disable). >>> This is done by adding the following to the manifest: >>> >>> <property_group name='general' type='framework'> >>> <!-- to start stop my service --> >>> <propval name='action_authorization' type='astring' >>> value='solaris.smf.manage.mysvc' /> >>> <propval name='value_authorization' type='astring' >>> value='solaris.smf.manage.mysvc' /> >>> </property_group> >> Can you point me at an example of such a profile? It's not clear >> to me what solaris.smf.manage.mysvc would look like. I'm guessing >> that it's just adding info to /etc/security/prof_attr and /etc/ >> security/exec_attr as described in the privilege debugging doc on >> opensolaris.org. > > I believe you need to define a new auth in /etc/security/auth_attr > and optionally associate that auth to a profile in /etc/security/ > prof_attr. The service manifest uses the new auth to declare the > service's required authorization. See /var/svc/manifest/network/smtp- > sendmail.xml for example. > >> Also, I'm assuming that I want this to be user daemon so how does >> that play into all of this? > > See Method Context section under smf_method(5) on setting privileges > for the service daemon. > > With respect to manifest reviewing, I'm sure one of us will have a > look if you send to this alias :) > > cheers, > -tony
