>> http://zhadum.east/export/ws/am223141/temp/nwam1-work/webrev/ >> >> 14499 remove solaris.network.autoconf.refresh authorization >> http://defect.opensolaris.org/bz/show_bug.cgi?id=14499 >> >> removes the solaris.network.autoconf.refresh authorization > Admittedly I haven't followed the auths changes much, but > one thing I don't get (and it's not part of these changes, I'd > just like to be able to make sense of it) - the Console User > is assigned the Network Autoconf User profile rather than > Network Autoconf Admin. Won't that preclude users creating > NCPs/ENMs/locations, since they don't have the > solaris.network.autoconf.write auth? Yes, that's exactly the point. We don't want to give Console User write privileges, because the user can change ipfilter and ipsec policies. This was the motivation behind creating the Autoconf User and Autoconf Admin. A user of a corporate laptop should be able to enable/disable profiles, but should not be able to modify profiles. These points came up during code review http://www.opensolaris.org/jive/message.jspa?messageID=412893#412893
> > Also, although the order in llibnwam ensures we don't > do the enable/disable request until after the enabled property > is set, I wonder if we should ensure that enable/disable actions > cannot half-succeed in door_if.c itself - i.e. to carry out an > enable/disable request, the user should have autoconf.write also. > Otherwise looks good. Thanks! Users shouldn't need the write auth to enable/disable profiles. When the "enabled" property is updated (as part of enabling/disabling profiles), nwam_check_auths() checks for autoconf.select auth (NWAM_FLAG_ENTITY_ENABLE is passed). Same argument as above, user should be able to enable/disable with the select auth and without the write auth. Anurag
