Hi Anurag, The main issue that I see here is that the Configuration GUI will need to change how it's run to have it run with possibly extra privileges so that it can write a new configuration - the panel element *should* be ok, but testing is the only way to confirm this...
The next question here too is w.r.t. way that it behaves if you don't have the ability to write - in that case, it's either going to totally refuse to run (not ideal) or allow a read-only view of the whole GUI where "write" access is needed (other than wlan of course). Right now the main configuration GUI simply will not run at all if you don't have the necessary privilege, but splitting it up like this changes things somewhat. If this goes ahead it's likely that, in the short term, especially at this late stage, that we would have to opt for the "not run at all" option if you don't have the "write" privilege, and put in an enhancement for a coarser control of the GUI features after we've done more investigation into whether it's really possible or not to work without the write privilege (I reckon it might be, but it's added testing - more test cases - and possibly more validation in the GUI before attempting a write, etc). Right now I couldn't put my finger on exactly how much work it would be to achieve, but it's better to avoid confusion than to make the user think they can do something and then fail miserably after making some modifications (akin to editing a root owned file, doing some edits and then finding you can't save since you forgot to su or pfexec before running the editor - very annoying). Just my 2 cents, Darren. On 12/ 3/09 03:02 PM, Anurag S. Maskey wrote: > To avoid design changes during code review, I'd like to get my version > of the solution for this RFE out for review right away. I have these > partially implemented and am currently testing different versions of > profiles and auths for different users and ironing out inconsistencies. > I will also spell out the final design in the bug comments. > > > There will be 5 different solaris.network.autoconf.* authorizations: > > * solaris.network.autoconf.read > allows to read any libnwam object and also get state > > * solaris.network.autoconf.refresh > needed to write any object and perform any action by nwamd > > * solaris.network.autoconf.select > mandatory to enable/disable profiles > > * solaris.network.autoconf.wlan > required to create/modify/destroy Known WLAN objects, also > select wifi network and wifi set keys > > * solaris.network.autoconf.write > required to create/modify/destroy any object other than > Known WLANs > > > The Network Autoconf profile will be broken up into two with the > following auths and profiles: > > * Network Autoconf User > solaris.network.autoconf.read > solaris.network.autoconf.refresh > solaris.network.autoconf.select > solaris.network.autoconf.wlan > > - allows the user to look at any object, create/modify/destroy > WLANs, get state, enable/disable profiles > - ideal for corporate laptop user > > * Network Autoconf Admin > Network Autoconf User > solaris.network.autoconf.write > solaris.smf.manage.location > solaris.smf.modify.location > > The Console User will have the Network Autoconf User profile. > Network Management profile will not have any Network Autoconf related > profile. > > > The users netcfg and netadm can have their profiles and auths modified > to take advantage of the new profiles. These are consistent with the > profiles and auths that these users currently have: > > * netadm > Network Autoconf Admin > Network Management > > * netcfg > Network Autoconf User > solaris.network.autoconf.write > > > > Some implementation details: > > When Known WLANs are committed and destroyed, a special flag > (NWAM_FLAG_ENTITY_KNOWN_WLAN) will be used. This flag will be passed to > nwam_check_auths() which tells it to check for > solaris.network.autoconf.wlan auth. > > When profiles are enabled and disabled, the "enabled" property is > modified and the object has to be committed. a special flag > (NWAM_FLAG_ENTITY_ENABLE) will be passed to commit in this case. This > flag, which is then passed to nwam_check_auths(), tells it to check for > solaris.network.autoconf.select auth. > > These flags will also be used in the backend door server to check for > auths. In the nwamd door server, the door requests will be used to > check for the appropriate auths. > > Thoughts? Comments? > > Thanks, > Anurag > > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
