Are system policies too restrictive?

[Cody A.W. Somerville]

Forwarding original e-mail from u-d-d:

On Fri, Jan 2, 2009 at 6:01 PM, Chris Coulson
<chrisccoulson at 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 at 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 at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090105/0e193cfa/attachment.html>