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). -renee
