Renee Danson Sommerfeld wrote:
> On Tue, Dec 15, 2009 at 11:39:45AM -0500, Paul Wernau wrote:
>   
>> Lin Ma wrote:
>>     
>>>>   
>>>>         
>>> We can do that, but it doesn't a good solution for me. It's not convenient.
>>> I'd like to see that Console User has full authorizations and normal
>>> user has *.read/refresh auths. If Console user is also using a
>>> 'restricted' version gui I may think about it. But it requires add
>>> 'Network Autoconf Admin:solaris:cmd:::/usr/bin/nwam-manager-properties:'
>>> to exec_attr. And I'm not sure whether it works and whether we need ARC
>>> it again.
>>>
>>> Renee, could you think it again to let Console User has Network Autoconf
>>> Admin profile?
>>>
>>>       
>> Doesn't this put us back into the same problem we were trying to avoid,
>> namely that the person who is logged into the system has full
>> administrative control of ipsec and ipfilter network policy?
>>     
>
> Yes, it does.
>
> The whole point of this work is to limit what the console user can
> do; the concern was that in giving the console user full network
> autoconf authorizations, we were giving too much power to the console
> user.  In the laptop case, that's okay; but on bigger systems, it is
> more often *not* okay.
>
> We want the default case to be that the console user can view current
> state, activate existing profiles, and view and modify the known wlan
> list.  Basically, the things you can do from the panel applet.  We want
> to restrict by default (this authorization profile could always be given
> to the console user if that's desired) the actual creation/modification
> of profiles that you can do via the full nwam-manager application.
>
> So we are creating two separate network autoconf profiles: one that
> allows the limited set of actions, which is given to the console
> user, and another which contains all network autoconf authorizations
> (and others as needed for service management).
>   
OK,  make sense. Let me try gksu solution.
If gksu works, I have to mention two problems:
1) since panel is not loaded by gksu, so even user has a root password 
and can access full GUI capplet, he still has to use restrict panel icon.
2) gksu run capplet as root user, capplet uses root's gconf settings. 
Though it may be not a problem now since Gui doesn't use gconf heavily, 
but it may be a problem in the feature.

Anyway I don't have any better solution now.

Thanks,
lin

Reply via email to