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
