Peter Memishian writes: > 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.
Besides the somewhat questionable duplication of the SCF mechanisms that Sowmini cites, there's another important problem with the existing dladm/dlmgmtd mechanism: security. The existing design checks that the caller holds sys_dl_config and/or sys_net_config, but then doesn't go on to audit this access-granting mechanism. The auditing (if any is done at all) is done out in the *client* (see audit_secobj in dladm), and not where the access itself is checked. Someone with those privileges could write his own non-auditing utility and just walk right by this security measure. That isn't supposed to happen. User space things should be checking authorizations (with chkauthattr(3SECDB)) instead of privileges, and then auditing the results at the point where the enforcement is done. Going forward, I think it'd be really nice to see this work done in SCF rather than scattered about in per-service daemons with local reinventions of locking, security, notification, and other issues. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
