Gary Winiger wrote:
> > > > > * 20 Questions states that ndmpd can be started manually
> > > > > from a shell. Why should this be? Isn't it an SMF service?
> > > > > What's wrong with svcadm enable svc:/system/ndmpd ?
> > > >
> > > > When the NDMP service is managed via SMF, it will support both
> > > > backup and restore operations but the team believes that there
> > > > is a benefit in providing profiles to allow sites to assign
> > > > backup or restore roles separately to users, with provision
> > > > to allow those users to manage (start, stop etc) the service.
> > > > The attached document provides definitions and an example.
> > >
> > > Hummm, I agree that "operators" should be able to backup,
> > > but not necessarially restore, while "system admins" should
> > > be able to do both. Rather than the existing proposal which
> > > mixes together SMF and pfexec, consider a purely SMF proposal.
> > > Have different service instances.
> >
> > This was the approach originally being pursued but we ran into
> > some limitations of the SMF implementation and changed tack.
> > IIRC, the challenge was how to enforce that SMF would only
> > allow one instance (of the three defined) to run at any time.
> > We assumed that this was the purpose of the single instance
> > flag but it didn't appear to work the way we anticipated.
>
> Talking with a member of the SMF team, indeed they
> say that is what the single instance statement means.
> Unfortunately there seem to be no implementation behind
> the statement. However, it was suggested that there could
> be a way to do this. Please consult smf-discuss at opensolaris.org.
>
> Let's not give up yet. IMO, this is the way in which the
> SMF/RBAC subsystem is intended to be use.
One suggestion has been to use a property to define the ndmpd
role (backup, restore, backup and restore), with the appropriate
authorization requireed to change the property, but I can't
put any more onto this project.
> > > One for backup and restore
> > > and one for backup only. Or maybe one for backup, one for
> > > restore and one that does both. Their enabling/disabling
> > > could be completely authorization driven.
> > > solaris.smf.manage.ndmp (for both), solaris.smf.manage.ndmp.backup
> > > (for only backup), and if a separate restore makes sense,
> > > solaris.smf.manage.ndmp.restore.
> > > Note that authorizations are hierarical so manage.ndmp includes
> > > backup and restore (above ;-).
> >
> > As there is no explicit requirement for separate backup/restore
> > roles at this time, I am going to defer this feature. We will
> > deliver a single service that supports backup and restore using
> > the pure SMF implementation suggested.
>
> I beg to differ. The RBAC evaluation requirements are for
> separation of services. And the default shipping system
> has separate Media Backup and Media Restore Rights Profiles.
Sorry, I should clarify, the implementation will still have
three profiles: NDMP Backup, NDMP Restore and NDMP Management:
NDMP Management will be the profile for managing the SMF
service (start/stop/refresh) and property values.
NDMP Backup will be added to Media Backup
NDMP Restore will be added to Media Restore
System Administrator already contains Media Backup
and Media Restore (no change required)
Alan
> > > I don't understand what is being driven at here and how it may
> > > or may not relate to audit.
> > >
> > > > The team requests that auditing
> > > > be a follow-on project, in the interest of not impacting dependent
> > > > projects.
> > >
> > > Again I can't see why there should be any impact. Adding audit
> > > is straight forward and IMO, seems to be required for this project,
> > > by the policy. It further seems odd that site administrators wouldn't
> > > be interested in what ndmp actions were made.
> > > I'm happy to work with the project team to define the events and
> > > supply sample code.
> >
> > Would it suffice to audit authentication events and backup/restore
> > job initiation and completion?
>
> Great. I thinks that's all that's required.
>
> > Suggestions for other events that you think should be audited are
> > welcome.
>
> Let's work out the content of the events off line from this case.
>
> > > Is there some where in the RBAC stuff that I could update to
> > > make this clear to project teams?
> >
>
> > We will remove the exec_attr entries for both ndmpadm and ndmpstat.
> >
> > Also, the value_authorization in the general/framework property group
> > should be solaris.smf.manage.ndmp (rather than solaris.smf.value.ndmp).
> > An updated version of ndmp_rbac.txt will follow once we hav
> > everything mentioned here addressed.
>
> OK. This seems like the right stuff.
>
> Gary..
>
