Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Allow non-Admin users to modify system preferences' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Allow non-Admin users to modify system preferences
Authored by: sgrey on Aug 07, '03 10:38:05AM

Well, I guess I got lucky when I tried this, because I didn't have much trouble. I will recheck things when I get to work today, but I'm sure it's working!

Now, in your step below, you cite:

>3. Set the new permissions...

>sudo chmod -R +s /System/Library/PreferencePanesDateAndTime.prefPane

What I did differently is leave the Date and Time pref pane alone, because I wanted everyone, admin or non-admin alike, to be able to access and change it. I only changed the permissions on pref panes I DIDN'T want non-privileged users to access, which was most of them. So for instance I'd log in as root and:

chmod -R u=rwx,g=r,o=r /System/Library/EnergySaver.prefPane

'cause I didn't want people messing with the Energy Saver.

then you get something like this:

ls -l /System/Library/EnergySaver.prefPane

and you get:

-rwxr--r-- 1 root wheel 749 Dec 4 2002 EnergySaver.prefPane

So everyone and wheel can still read it, but only root can change it.

Honestly, I ain't lying, it works like a charm! When a non-privileged user logs in and calls up System Preferences, they can see all the pref panes, but when they go to click on one for which the privs have been altered it gives them an error message.

I guess the "+s" you specified above is a perm option, and I don't know how that works.






[ Reply to This | # ]
Allow non-Admin users to modify system preferences
Authored by: masskinner on Aug 07, '03 11:14:40AM

I believe this technique works for you, but only because the System Preferences you are dealing with are accessible to unprivileged users by default. If you try this trick with DateAndTime, it will not work.

chmod -R +s recursively sets the user id (SUID) on execution.

So far, modifying the /etc/authorization file seems to be the best solution. Perhaps the trick is to combine that with file permissions as well. In other words: modify the authorization file to allow everyone to modify the system prefs, then lock the users out of certain system prefs by changing the individual file and folder permissions. -S

[ Reply to This | # ]