http://defect.opensolaris.org/bz/show_bug.cgi?id=11321
--- Comment #1 from Anurag S. Maskey <Anurag.Maskey at Sun.COM> 2009-11-30 20:43:12 UTC --- (In reply to comment #0) > The Network Autoconf profile should be split into two separate profiles: one > that's appropriate for the console user, which allows profile selection and > status viewing, and one that allows profile creation/modification/destruction. Looking at the authorizations required, it appears that it is not possible to break down the profiles as above without adding new authorizations. Profile selection (and also wlan selection) requires solaris.network.autoconf.refresh and solaris.network.autoconf.write authorizations. Once the user has the write authorization, profiles can be created or modified or destroyed. I found the following comments from code review feedback: > > Renee Danson Sommerfeld wrote: > > > > * We could make this scheme more locked down out-of-the-box, and also more > > flexible, by splitting the Network Autoconf profile into separate nwam > > user and nwam admin functions. The Console User would have the former, > > Primary Admin the latter. From the GUI point of view, I think we could > > tailor the split such that the panel applet functions (choose a location, > > choose a wlan, create a wifi key) would be allowed for the nwam user, and > > the config tool functions (create/modify profiles) would be allowed for > > the nwam admin. > > > > I think this could be a fairly straightforward enhancement we should > > pursue quickly after integration. > > > Paul Wernau wrote: > > OK. For a corporate-supplied laptop where the user has no > administrative privileges (fairly common), the user should be able to > use NWAM in the sense of plugging into arbitrary ethernet ports or > connecting to arbitrary wifi points, but they shouldn't necessarily be > able to change firewall or IPsec policy with express permission or do > other administrative-like things. I think what we need is a new authorization that allows (sat solaris.network.autoconf.select) which allows enabling/disabling of profiles. If such an authorization exists, then the "autoconf user" would have the read, select, refresh authorizations and the "autoconf admin" would have all read, select, refresh, write. We may also have to add a different authorization that allows create/modify/destroy of the Known WLAN objects as the "autoconf user" is expected to choose wlans and create wifi keys. thoughts? -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
