On Fri, Jan 2, 2009 at 6:01 PM, Chris Coulson <chrisccoulson@googlemail.com> wrote:
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
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
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: cody.somerville@canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Are system policies too restrictive?
