≡

wincent.dev

  • Products
  • Blog
  • Wiki
  • Issues
You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.
Home » Issues » Feature request #133

Feature request #133: REQUEST: Limited access to preferences/features for non-admin users

Kind feature request
Product WinSwitch
When Created 2005-03-10T01:24:16Z, updated 2010-08-12T10:12:46Z
Status closed
Reporter DaMacGuy
Tags no tags

Description

Is there a way to limit access to WinSwitch settings to non-admin level users?

I'd really rather not have a user on a machine be able to turn on "show root" or change the display, or even easily go to the Accounts preference pane (of course they can still get to it from System Preferences, but why make it obvious).

Comments

  1. Greg Hurrell 2005-03-10T03:22:36Z

    I agree this would be a good thing to have as an option. The only question is, how should it be done? When I say "how" I'm not so much referring to the technical implementation side as to the user interface side.

    There a few options:

    1. Remove the "Show root user" and "Open Accounts..." items when running under non-administrator accounts. In other words, it wouldn't be optional, but a blanket thing applied automatically.

    2. As above, but instead of removing (hiding) the options, ghost them out.

    3. As above, but instead of removing or ghosting, show a dialog when a non-administrator user tries to use them explaining why they can't do it.

    4. As per "3", except instead of just showing the dialog actually prompt for a password and allow them access if they enter it correctly. This one is slightly tricky and I am not all that inclined to do it.

    5. Provide a special user interface for admin users which allows them to manage the privileges of non- admin users. This could mean having white lists (non-admin users on the list have the privileges but all others don't), black lists (users on the list don't have the privilege if they're on the list, otherwise they do), or a simple check box which turned the privileges on/off for all non-admin users at once.

    6. Permit the same kind of customization, but instead of developing a full-blown UI for it make it a command-line-only feature.

    There are a couple of questions to be resolved in the cases of options "5" and "6". Like, what happens if one admin tries to set things up a certain way and another tries another way? How is the conflict resolved? How are these system-wide preferences managed in a way that only admin users can change them? Do we have an admin-group writable prefs file in /Library/Preferences/?

    Basically, I would want to come up with a proposal that is both elegant (ie. it works simply and it works well) and flexible (ie. it works in a way that everyone is happy with). I don't think it will be that easy, but perhaps through discussion here we can come up with a good plan.

    Marking as ASSIGNED.

  2. DaMacGuy 2005-03-13T03:37:35Z

    This is why you're a developer - I don't think I would have thought of more than half of those options. (grin)

    If I had to pick three of those options I'd consider 1, 2, and 4.

    1 offers the ability to not confuse users without access to change the options.

    2 offers the ability for a user with admin access who migh tbe logged in as another user to recognize that he needs to change to another account.

    4 allows the user from 2 to have the ability to still make the change w/out resorting to switching accounts.

    Whichever is easiest to implement.

    (In reply to comment #1)

    I agree this would be a good thing to have as an option. The only question is, how should it be done? When I say "how" I'm not so much referring to the technical implementation side as to the user interface side.

    There a few options:

    1. Remove the "Show root user" and "Open Accounts..." items when running under non-administrator accounts. In other words, it wouldn't be optional, but a blanket thing applied automatically.

    2. As above, but instead of removing (hiding) the options, ghost them out.

    3. As above, but instead of removing or ghosting, show a dialog when a non-administrator user tries

    to

    use them explaining why they can't do it.

    4. As per "3", except instead of just showing the dialog actually prompt for a password and allow

    them

    access if they enter it correctly. This one is slightly tricky and I am not all that inclined to do it.

    5. Provide a special user interface for admin users which allows them to manage the privileges of

    non-

    admin users. This could mean having white lists (non-admin users on the list have the privileges but

    all

    others don't), black lists (users on the list don't have the privilege if they're on the list, otherwise they do), or a simple check box which turned the privileges on/off for all non-admin users at once.

    6. Permit the same kind of customization, but instead of developing a full-blown UI for it make it a command-line-only feature.

    There are a couple of questions to be resolved in the cases of options "5" and "6". Like, what

    happens

    if one admin tries to set things up a certain way and another tries another way? How is the conflict resolved? How are these system-wide preferences managed in a way that only admin users can

    change

    them? Do we have an admin-group writable prefs file in /Library/Preferences/?

    Basically, I would want to come up with a proposal that is both elegant (ie. it works simply and it

    works

    well) and flexible (ie. it works in a way that everyone is happy with). I don't think it will be that easy,

    but

    perhaps through discussion here we can come up with a good plan.

    Marking as ASSIGNED.

  3. Greg Hurrell 2006-07-05T02:04:25Z

    Changing assignment to reflect my new email address.

    https://wincent.dev/a/news/archives/2006/05/change_of_email.php

  4. Greg Hurrell 2010-08-12T10:12:13Z

    I'm marking all WinSwitch issues closed seeing as I personally no longer use it, and in fact haven't for around 4 years now.

    WinSwitch addressed a real problem with the initial implementation of Fast User Switching in Panther (released October 2003), namely, the excessive screen real estate that it chewed up. Apple fixed that problem in Tiger, if I recall correctly, which came out in April 2005 (or if I'm wrong about it being Tiger, then it was definitely fixed by the time Leopard came out, in October 2007).

    With this change, most of the justification for WinSwitch's existence went away, at least for me. So that's why I'm going to close all these tickets: I can't really support something that I don't use myself.

    But it's open source, so if any one wants to tackle any of these issues and submit patches, I'll be happy to accept them.

  5. Greg Hurrell 2010-08-12T10:12:46Z

    Status changed:

    • From: new
    • To: closed
Add a comment

Comments are now closed for this issue.

  • contact
  • legal

Menu

  • Blog
  • Wiki
  • Issues
  • Snippets