Forwarding original e-mail from u-d-d: <div class="gmail_quote">On Fri, Jan 2, 2009 at 6:01 PM, Chris Coulson <<a href="mailto:chrisccoulson@googlemail.com">chrisccoulson@googlemail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, I came across a bug report recently where users were having problems authenticating with PolicyKit from tools such as users-admin, because the 'Unlock' button was greyed out. After some debugging, it seemed that all affected users were logged in via a VNC session. Because the VNC session was not on the active console, users could not authenticate with Policykit, because of the default Ubuntu policy. I closed the bug report, as Policykit was doing it's job, and I pointed out to the affected users that they can change the system policy if they want. It seems that this is confusing users that are logging in from a remote console. In the pre-Hardy days when Policykit didn't exist, users could launch any admin tool and authenticate with gksu whether they were on a local or remote console. This has changed now, and results in a loss of functionality for those users who log in on a remote console. We now have to be on the active local console to do pretty much anything, from adding/removing users to adjusting the clock. I can understand why certain actions are restricted to users logged in to the active local console (such as shutting down/rebooting/suspending the machine, mounting/unmounting removable media, accessing certain hardware devices such as sound cards/web-cams), but I'm not sure why the default policy should prevent administrators from changing system settings (such as adding users, changing the system time etc.) when they are logged in from a remote console. The extra policies that appeared in Intrepid for the new Jockey seem to be a lot more sane than existing policies. For example, they allow administrators to install or remove device drivers regardless of whether they're on the local console or not. I think this is how some of the other policies should be. What do you think? Are the default policies too restrictive? Regards Chris -- Ubuntu-devel-discuss mailing list <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> </blockquote></div> In my opinion, I don't think graying out the unlock box is correct under any, if not most, circumstances. Instead, when the user clicks the unlock button they should be presented with the same authentication box and they (or in most use cases, another user who does have permission) can attempt to authenticate and be presented with the reason why they can not and what they have to do to be able to do so (ie. be logged in locally, seek an administrator, etc.). However, back to your OT about the default restrictions being too strict, I personally have no strong feelings either way. I suppose its a question of if we should make it easy or not to allow the user to shoot themselves in the foot or not by default. Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: <a href="mailto:cody.somerville@canonical.com">cody.somerville@canonical.com</a>