Darren Kenny wrote: > 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,
Thanks for your comments, you bring up important issues that I didn't think would be very complex before. I am looking at the GUI and thinking that the changes may not be very straightforward. I like the "don't show it if the user doesn't have permission". But the GUI is a bit more complicated and this may not work. The WLANs are integrated with the wireless NCUs. So, if the user has just the auth to change wlans but no write, the GUI will still have to be started. The same goes for users that have permissions to enable/disable profiles/objects but no write permissions. One approach that I think might work (since I don't know the underlying GUI details) is to start the GUI if the user has the solaris.network.autoconf.read auth. Then, fields/buttons are disabled if the user doesn't have the appropriate auth (there is no separate view like list for nwamcfg). So, if the user has solaris.network.autoconf.wlan auth, then the buttons in the wireless tab will be enabled, otherwise disabled. If the user has solaris.network.autoconf.enable, then the start/stop buttons for VPN, enable disable for NCUs, and switching locations will be enabled. The remaining buttons and fields will require the solaris.network.autoconf.write auth. These are just my high-level thoughts, I am sure its not as simple as it sounds. Because the new authorizations are fine-tuning the current auths, the checks will have to be at a lower level than just whether to start the GUI or not. I see this RFE will be pursued only if the GUI can make changes prior to phase 1 integration (similar to the multiple NCP support). We can, however, complete the design now and come to agreement on the authorizations for the new profiles even if we don't decide to finish for the initial putback. Anurag > 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 >>
