On 10 Dec 2009, at 12:40, Lin Ma wrote: > 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).
Yes, that sounds okay to me. We do have some other applications on the desktop (and possibly capplets, I forget off-hand) that use gksu to prompt for a suitable admin password if you don't have the correct privileges, so I guess we might get some bug reports from users asking why they can't do that with the NWAM capplet as well. But I suppose that's really the other applications' problem, not ours, as using gksu presumably isn't a very RBAC-friendly solution. > 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? Not sure I understand your point about showing more information in the panel icon... or did you mean 'less information', not 'more'? For panel icon menu items, I think I would prefer to hide menu items altogether that the user did not have sufficient privileges to use. Menu items should normally only be disabled if they might become enabled by performing some other action in the GUI, which isn't really the case here. Hiding such menu items altogether should generally make it clearer when somebody is using a 'restricted' version of the GUI. We would probably need to mention this in the OLH, so cc'ing Juanita to make her aware... Thanks, Calum. > 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 >> > -- CALUM BENSON, Interaction Designer Sun Microsystems Ireland mailto:calum.benson at sun.com OpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
