> >> In the case of 'libipadm' model, there will be user called 'ipadm' who > >> owns the 'datastore'. Read/Write to this data store will be done through > >> 'libipadm' after donning that role. > > > > How does that happen? Libraries themselves don't have the ability to > > run setuid. > > > > Agreed. > > We need to provide 'file_dac_write' privilege to 'ipadm' command along > with 'sys_ip_config and proc_audit'. So in /etc/security/exec_attr we > should have a line like this for 'ipadm' > > Network Management:solaris:cmd:::/sbin/ipadm:euid=ipadm;egid=sys; > privs=sys_ip_config,proc_audit,file_dac_write. > > This should allow 'write' access to the db store 'ipadm.conf (owned by > user ipadm)', from within the library, irrespective of any user with > right authorization executing 'ipadm'. Further whoever links to > libipadm.so.1 library should provide this privilege for that utility or > daemon.
While this will work for ipadm, I don't think this is architecturally sound. For instance, consider the case where an application links against a library (e.g., libnwam) that in turn links against libipadm. Now that application needs to have something in /etc/security/exec_attr to satisfy an implementation detail of libnwam (the fact that it uses libipadm). As Seb mentioned earlier, dlmgmtd provides this facility for libdladm. It also synchronizes all changes (e.g., two applications using libdladm at the same time cannot clobber each other), and provides a central point for other facilities, such as posting sysevent notifications for new datalinks. -- meem
