Hi Renee, Renee Danson Sommerfeld wrote: > Hi Darren, > > Apologies for the delayed response; comments in-line. > > On Thu, Dec 03, 2009 at 03:22:33PM +0000, 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... >> > > That split--between panel element and config gui--was where we were trying > to draw the line. It seemed reasonable to say that whoever is logged in > on the system console should be able to choose the connection policy; but > actual creation of that policy was something that might need to be more > restricted on some systems. Not a really big deal on laptops, but laptops > cannot be our only focus; and it's harder to make things *more* restrictive > moving forward. Hence the desire to make this change before our initial > integration. > > >> 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 >> > > Though this obviously is not the top choice, I would prefer to start out > with the "not run at all if not privileged" approach. My rationale is > what I mentioned earlier: I think it's better to start out restrictive, > maybe even limited, and then make things more open later. If we didn't > do the split now, then folks would get accustomed to being able to create > config without having the appropriate authorizations, and changing that > down the road would feel like functionality being taken away. > > So, I'd like to focus on nailing down what *can* be done prior to > integration. From the ON/authorization point of view, I think Anurag > has a good approach, and I think the ON implementation is quite feasible. > So we need to determine what minimal set of changes is required in the > GUI to cope with that split, and how much work it will take to implement > that. > Darren and I thought for short-term solution, we need reduce Gui change as possible as we can. So for the capplet, if fails gracefully if the user don't have the necessary auths (i.e. a message box). We can change the Gui daemon (the panel icon) to include more information (e.g. IP address), make menu-items insensitive if the user don't have the 'select' auth, or even don't show wlans if there is an auth for scan it. Calum, what do you think about it? My rough estimation for the require time is 3 weeks. Anyway it depends how many the Gui change are.
Thanks, lin > Is that something you and Lin can discuss, and come up with an estimate > for? > > Thanks! > renee > > > >> (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 >>> >> _______________________________________________ >> nwam-dev mailing list >> nwam-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/nwam-dev >> > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev >
