[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-smf-discuss
Subject:    Re: [smf-discuss] smf manifest questions for a new daemon
From:       Michael Corcoran <Michael.Corcoran () Sun ! COM>
Date:       2009-11-24 20:25:27
Message-ID: E0E67711-5CB7-4C0E-A50E-185673BD5AEF () Sun ! COM
[Download RAW message or body]

Hi Tony and others,

I've attached the latest versions with the auths and method context.   
One question I do have is about updating prof_attr.  Are there any  
rules surrounding how to update this file?  Currently I've added  
solaris.sfm.manage.acpihpd to the "Maintenance and Repair" profile  
since it makes sense there but I could also create a separate profile  
just for this daemon and then also include it in "Maintenance and  
Repair".  It seems odd to make a profile just for this one daemon.

I'd appreciate it if you could take a look.


["acpihpd.xml;" (application/xml)]

Thanks,

Mike

On Nov 22, 2009, at 10:21 PM, Tony Nguyen wrote:

> Mike,
> 
> I had a look but the manifest contains neither the recommended  
> authorization properties nor method context. I'd be happy to review  
> once the team figure out the security model and implement the  
> authorization properties and method context.
> 
> -tony
> 
> Michael Corcoran wrote:
> > 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
> > 
> 



_______________________________________________
smf-discuss mailing list
smf-discuss@opensolaris.org

[prev in list] [next in list] [prev in thread] [next in thread]