> >> Assuming we go with the "root" with dropped privileges approach, please
> >> provide us guidance for the specific issues:
> >>
> >> o where would you recommend that the persistent config files belong.
> >> Would having them in /etc/ilbadm directory still be appropriate.?
> >>
> >
> > Ideally it would not exist and be a [set of] smf properties.
> > Since I believe we've already been down that path and the file
> > is too complex for properties, what's wrong with the use of
> > /etc/ilbadm/*? Is the issue that ilbd can't hold the files open
> > and needs create access in that directory so it can do atomic
> > renames?
> >
> Gary,
>
> We plan to use /etc/ilbadm/* for storing the persistent config. Is
> there a existing Solaris feature that implements the "root" with dropped
> privileges approach that we can use as reference?
See callers of __init_daemon_priv(), __fini_daemon_priv(),
__init_suid_priv(), __priv_bracket(), __priv_relinquish()
> Also recall that ilbadm has two sets of commands - one is for viewing (
> ie statistics, load balancing rules etc..) and the other is for
> configuration ( creating rules/adding removing backend servers ,
> enabling/disabling rules etc). We would like the viewing related
> commands to be accessible by all and some form of authorization for the
> configuration commands. It is also important that the task for user to
> set up the authorization for this task is minimal and easy to do
>
> Can you kindly provide input on what you would recommend in terms of
> authorization? Again a reference to a Solaris feature that implements
> the authorization in a similar way would be much appreciated.
Take a look in /etc/security/auth_attr. Perhaps something like
solaris.network.loadbalance.write or solaris.manage.loadbalance
See what fits, or start anew. What's important is the Rights
Profile (see /etc/security/prof_attr) that you either include
the authorization in or create anew. That's the real administrative
interface. The authorization is just the implementation interface.
Gary..
