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. > >> 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. Also, I'm assuming that I want this to be user daemon so how does that play into all of this? > >> I'm also looking for a volunteer to review the manifest to make >> sure all of the required fields are there and it is as secure as >> possible. >> >> > I'd be happy to take a look, but it'd probably be good for > someone on the SMF team to give it a once-over too. I've attached the manifest and the start/stop script as well as an email with questions I'm trying to answer for PSARC :) I'm having Intel figure out the minimum privileges we need based upon running the daemon and seeing which privileges it uses and thus we can limit the method context to just those privileges which I think is Gary's main question in the attached email. Thanks, Mike > -------------- next part -------------- A non-text attachment was scrubbed... Name: svc-acpihpd Type: application/octet-stream Size: 489 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20091120/510ac4c0/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: acpihpd.xml Type: text/xml Size: 1299 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20091120/510ac4c0/attachment.xml> -------------- next part -------------- An embedded message was scrubbed... From: Gary Winiger <g...@eng.sun.com> Subject: RE: acpihpd ACPI Hotplug Daemon [PSARC/2009/551 fast-track timeout 10/19/2009] Date: Mon, 16 Nov 2009 15:26:19 -0800 (PST) Size: 5659 URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20091120/510ac4c0/attachment.nws> -------------- next part -------------- > > Alan
