Forwarding original e-mail from u-d-d:<br><br><div class="gmail_quote">On Fri, Jan 2, 2009 at 6:01 PM, Chris Coulson <span dir="ltr">&lt;<a href="mailto:chrisccoulson@googlemail.com">chrisccoulson@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I came across a bug report recently where users were having problems<br>
authenticating with PolicyKit from tools such as users-admin, because<br>
the &#39;Unlock&#39; button was greyed out. After some debugging, it seemed that<br>
all affected users were logged in via a VNC session. Because the VNC<br>
session was not on the active console, users could not authenticate with<br>
Policykit, because of the default Ubuntu policy. I closed the bug<br>
report, as Policykit was doing it&#39;s job, and I pointed out to the<br>
affected users that they can change the system policy if they want.<br>
<br>
It seems that this is confusing users that are logging in from a remote<br>
console. In the pre-Hardy days when Policykit didn&#39;t exist, users could<br>
launch any admin tool and authenticate with gksu whether they were on a<br>
local or remote console. This has changed now, and results in a loss of<br>
functionality for those users who log in on a remote console. We now<br>
have to be on the active local console to do pretty much anything, from<br>
adding/removing users to adjusting the clock.<br>
<br>
I can understand why certain actions are restricted to users logged in<br>
to the active local console (such as shutting down/rebooting/suspending<br>
the machine, mounting/unmounting removable media, accessing certain<br>
hardware devices such as sound cards/web-cams), but I&#39;m not sure why the<br>
default policy should prevent administrators from changing system<br>
settings (such as adding users, changing the system time etc.) when they<br>
are logged in from a remote console.<br>
<br>
The extra policies that appeared in Intrepid for the new Jockey seem to<br>
be a lot more sane than existing policies. For example, they allow<br>
administrators to install or remove device drivers regardless of whether<br>
they&#39;re on the local console or not. I think this is how some of the<br>
other policies should be.<br>
<br>
What do you think? Are the default policies too restrictive?<br>
<br>
Regards<br>
<font color="#888888">Chris<br>
</font><br>--<br>
Ubuntu-devel-discuss mailing list<br>
<a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a><br>
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><br>
<br></blockquote></div><br>In my opinion, I don&#39;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.).<br>
<br>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.<br>
<br>Cheers,<br clear="all"><br>-- <br>Cody A.W. Somerville<br>Software Systems Release Engineer<br>Custom Engineering Solutions Group<br>Canonical OEM Services<br>Cell: 506-449-5899<br>Email: <a href="mailto:cody.somerville@canonical.com">cody.somerville@canonical.com</a><br>