Re: Authentication in PreferencePanes
Re: Authentication in PreferencePanes
- Subject: Re: Authentication in PreferencePanes
- From: Eric Peyton <email@hidden>
- Date: Thu, 1 Nov 2001 13:41:44 -0600
On Thursday, November 1, 2001, at 12:30 PM, Kevin Bohan wrote:
Hi,
This is somewhat related to my previous mailing. I have been
considering whether or not I need to add an authentication control to
my preference pane. However, I could not find a document anywhere that
defined under what circumstances a preference pane should include a
lock/unlock control, and under what conditions the control should
appear locked or unlocked.
So I did some investigation myself and found some interesting behavior
in the various System pref panes that include lock controls.
The pref panes I looked at were as follows:
1) The "Login Window" tab of the "Login" pref pane.
2) The "Energy Saver" pref pane.
3) The "Startup Disk" pref pane.
4) The "Users" pref pane.
My conclusions are as follows:
a) If I am logged in as an Administrative user then the lock on all
these System pref panes is always unlocked when I first launch the
System Preferences application. This is regardless of the state of the
locks when I last quit the System Preferences app.
This is correct.
b) Although, this is not what I would intuitively expect, if I then
lock any one of these System pref panes, all the other System pref
panes are also locked. They are all linked. Is this by design?
Yes, they all use the same authentication method.
c) For unlocking the reverse happens, in that all pref panes
simultaneously unlock.
As designed.
d) Even if I lock the lock, I can usually still access the preference
file saved in /Library/Preferences.
The lock/unlock allows you to access a tool which does the actual
updating of those files. The lock/unlock does not in any way affect the
on disk permissions of those files.
For example, lock the lock on the Energy Saver and go to its
preferences file at
/Library/Preferences/com.apple.PowerManagement.plist. Use vi or the
Property List Editor to make changes to the file and you have no
problem saving the changes.
Caveats:
If I lock a pref pane, ie all pref panes, all someone has to do is quit
the System Preferences application and open it again to have unlocked
access to the pref panes. This makes the lock a bit pointless, what?
What's the point of the lock when I'm an admin user. Is it to prevent
someone coming up to your machine and making changes while you're
logged in. If that's the case, then it shouldn't be this easy to get
around, surely!
e) If I am logged in as a non-administrator whenever I open the System
Preferences all locks are always locked.
If they are an admin, they start up unlocked for them. If they are a
normal user they start up locked and the user must unlock it.
What the lock allows you to do ...
a) Go to a friends machine who is NOT an admin, but you ARE an admin on
(say you are the lab admin)
b) Open up preferences, it is locked. Friend asks you to change the
login prefs on the machine.
c) You unlock and change the preferences
d) You lock the preference
e) Friend is still locked out.
f) Again all locks are linked. Locking/unlocking one affects all other
locks.
They are *now*. There is no guarantee that they will be forever. The
system does include the ability to authorize a user based on specific
rights (i.e. a specific user can set the date, but can't change the boot
device, etc.). Preferences is currently only checking for admin
authorization.
g) You cannot easily access the /Library/Preference files directly, so
no loophole there.
Is this the way it's supposed to work. If so, then where is this
documented.
Yes. In the system overview I believe.
In either case, I propose that this stuff should be documented,
especially as we can now legitimately write Pref panes. The
documentation should cover:
1) Under what circumstances should you include a lock/unlock mechanism.
2) When it should appear locked vs unlocked, if that's something you
have to code for.
Does your preference access system wide resources or user based
resources?
I also propose that the lock/unlock control called
NIAuthenticationButton should be made publicly available so that we
don't all start implementing slightly different versions of this, very
useful and possibly very common, control in the context of preference
panes.
That will not happen. The NIAuthenticationButton will not become
public, however some other version of an authentication button may or
may not be made public in the future. NO time frames. It is a current
issue of discussion.
Eric
_________________________________________________________________
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev