Sangeeta Misra writes: > On 06/15/09 11:46, Tom Whitten wrote: > > Sangeeta Misra writes: > > > >> Folks, > >> Currently ilbd daemon runs as "root" and uses SCF to store persistent > >> configuration. ILB's rules, servergroups and healthcheck objects are > >> represented as property groups in SCF. Note that we use the property > >> group type SCF_GROUP_APPLICATION. > >> > >> > > [SNIP] > > > >> Question 1 > >> =========== > >> I assume in order to authorize ilbd daemon to successfully call the the > >> scf_* functions to create/modify /delete/retrieve the configuration > >> to/from scf framework, all I need to do is add this to > >> usr/src/lib/libsecdb/user_attr.txt : > >> > > > > I'll let Gary comment on modifications to > > usr/src/lib/libsecdb/user_attr.txt. > > > > > >> daemon::::auths=solaris.smf.manage.ilb,solaris.smf.modify ( or should > >> this be solaris.smf.modify.application?) > >> > > > > > > Notice that currently user_attr has this: > dladm::::auths=solaris.smf.manage.wpa,solaris.smf.modify > > So a process running as "dladm" also runs the same risk. > > At this point I am thinking I should EITHER run ilbd as "root" ( with no > new entry in user_attr) OR with a new uid "netadm" ( this will be a uid > that all networking projects like NWAM, Brussels, ILB etc can use) and > have this entry in user_attr.txt: > > > netadm::::auths=solaris.smf.manage.ilb,solaris.smf.modify > > I am waiting for Gary to let me know what is the best solution. > > Sangeeta
Certainly, Gary has a lot better understanding of the security issues than I do. I'd still prefer to see you use solars.smf.modify.application instead of solaris.smf.modify. Have you encountered a situation where solars.smf.modify.application is not sufficient? tom
