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

Create 'managed' admin users System
I work for a university, and we have been having some difficulty deciding on a way to handle permissions for our faculty and staff. We want them to be able to install into /Applications, but we do not want for them to be able to access the more "sensitive" preference panes (such as network). Previously we tried creating a new group and using it to limit access to System Preferences, but we later found that this breaks, making System Preferences completely inaccessible (apparently it likes to remain part of the "wheel" group).

So what to do? Here's a possible solution for 10.3. Make a new user using the "Accounts" preference pane. Click on "Limitations" and choose "Some Limits." Uncheck "Open all System Preferences." The user will now be unable to open important preference panes.

Now open Netinfo Manager and authenticate. Click on Groups and then choose the Admin group. Click on the users property and then hit Command+Option+N to insert a new value. Type in your new user's short name. Save your changes with Command+S and quit.

Now in System Preferences you should see that your new user is described as being Admin, Managed. Your user can now install into Applications, but have no access to the crucial system preference panes! Of course this probably isn't 100% secure, as an Admin user could probably find a workaround for this limitation. However, it appears to have solved our problem in a simple way, without having to extensively modify the overall system permissions.

[robg adds: I haven't tested this one, and I think the security caution is a good one -- this may work for simple cases, but it's not designed to keep a dedicated tweaker out of the key areas of the system. Can anyone comment on a more secure way to accomplish the same result?]
    •    
  • Currently 3.00 / 5
  You rated: 4 / 5 (5 votes cast)
 
[22,421 views]  

Create 'managed' admin users | 17 comments | Create New Account
Click here to return to the 'Create 'managed' admin users' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Create 'managed' admin users
Authored by: vondrix on Mar 26, '04 10:57:00AM

The problem is that all the people in the admin group, can use sudo to get execute commands as root. Most preference-panes just modify text-files in /etc. sudo pico /etc/hostconfig is basically the same as using the Sharing preference pane. Adding a new user can be done by using the nicl utility.

I think it would be better to change the permissions on the /Applications folder. Add a group "caninstall", change the group of Applications to "caninstall", and put all the people that should be able to install, in the caninstall group.

If you want to keep Applications owned by the admin group, you should disable Terminal access for those managed admins, and you should change the /etc/sudoers file to only list the real admins.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: kirkmc on Mar 26, '04 01:10:05PM

I agree with Vondrix's comment. It makes no sense to limit someone to certain preference panes then give them admin access; they can do anything they want, such as, for example, change their own limitations in the Accounts preference pane.

So I tried it to see what would happen... I couldn't log in on _any_ other account than the one I made the change from. I had to kill the user from another machine. When I removed the user from the admin group, I was able to log in anew.

My advice - find another way.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: Anonymous on Mar 26, '04 02:34:29PM

/etc/authorization allows you to give non-admin users the ability to do things, like install things into the "admin" areas like /Applications and /Network, in addition to much much more.

That is a much better way of doing this. Elevate a non-admin as opposed to demoting an admin. As other posters have mentioned, since they can still do sudo and other CLI commands it would be trivial to remove the MCX info from their account. This is security through obscurity at best.

More info on my site.

Joel

www.afp548.com
mactroll@afp548.com



[ Reply to This | # ]
More on /etc/authorization?
Authored by: klktrk on Mar 26, '04 02:45:32PM

This is really interesting, and I was totally unaware of the /etc/authorization file. Looking at the file, it's in a .plist format, though it doesn't have the extension.

Does anyone have a good resource, faq, or tutorial on how to configure this file?



[ Reply to This | # ]
More on /etc/authorization?
Authored by: peterneillewis on Mar 26, '04 10:08:49PM

I don't know if I would call it a good resource, but you can find out more information at:

http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/index.html

It is more of a programmer's resource for adding support to your application (for example we used it in Interarchy to allow administrators to limit access to the network traffic watching facility), but I haven't seen much else around, so perhaps this is as good as it get.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: andyinindy on Mar 26, '04 09:13:37PM

Thanks, Joel, for pointing this out. I had no idea that this existed either. I agree that it makes more sense to add privileges to a normal user than to demote an admin. Glad to see that there is an alternative. This is exactly what I was angling for with this hint... some expert advice!

afp548 rocks, BTW! Tons of great articles.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: klktrk on Mar 26, '04 02:41:15PM

As per Vondrix's suggestion, the more secure way to solve a problem is only grant the privileges necessary. In this case, you basically want to give certain users the right to install software in the Main /Applications folder on the computer. So, keeping security in mind, you don't look for a way to up the user's privileges across the board and then limit them in some llittle ways, you look for a way to enable them to JUST do that added thing you want to let them.

Vondrix's suggestion would work. You could follow it up with the following bash code added to /etc/daily.local which would ensure that the Applications folder would continue to have the appropriate permissions.

chmod 775 /Applications; chown root:caninstall /Applications

where "caninstall" would be the group name you've given installation privileges to.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: Anonymous on Mar 26, '04 04:24:43PM

We had this same discussion with our Apple Eng a couple of weeks ago. My users need admin rights, but I didn't want them playing with thier pref panes ( i.e. remote desktop ) So what we determined was removing the actual pane from System:Library:PrefrencePanes ( ARDPref.prefPane ) after making the settings in Remote Desktop. This alows Remote Desktop to work, but the pref pane is gone in System Preferences. Even with Admin Rights, without the actual pane, no changes can be made. I keep a copy of the pane on the server that onlly I have access to. It seems to be working really nice so far.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: TvE on Mar 26, '04 04:44:34PM

Can't the user use "defaults" to set different settings for the prepane - or even provide their own copy of the prefpane?



[ Reply to This | # ]
Create 'managed' admin users
Authored by: JohnnyMnemonic on Mar 27, '04 01:10:06AM

The problem with this is illustrated by an example: we moved the System Preference for "Software Update"; we didn't want our users installing an update that we haven't had the chance to test first. Problem is, they could just use the terminal to "softwareupdate". Removing sudo permissions in /etc/sudoers only changed sudo on the command line; users could still unclick locks in the GUI (for example, to change permissions on directories, and reaccess the hidden preference pane).

Finally, we found that changing permissions on System installed items were "fixed" the next time "Fix Permissions" was run by Disk Utility, which, IIRC, doesn't even require admin rights to do.

The best solution is to modify /etc/authorization, as Joel says, but I've found the documentation for it cryptic at best.

The real solution is to set up Network Authentication + WorkGroup Manager, but that requires the care and feeding of a server.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: Durandal on Mar 26, '04 06:54:34PM

Bad, bad idea. If you put a user in the admin group, he's added to the sudoers file. With sudo access, not being able to access important preference panes is basically irrelevant.

---
Damien Sorresso



[ Reply to This | # ]
Create 'managed' admin users
Authored by: Whosawhatsis on Mar 26, '04 08:07:50PM

I get the impression that this is designed to restrict the type of people who wouldn't know what to do with sudo (on the off chance that they had even heard of it). The reason for keeping them from messing with the stuff is primarily because they don't know what they're doing and could only mess things up.

---
I was offered a penny for my thoughts, so I gave my two cents... I got ripped off.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: andyinindy on Mar 26, '04 09:28:36PM

As some of you have pointed out, this hint is far from perfect. I have since found that creating an "Admin, Managed" user in this way breaks fast user switching (not that I would enable it on a faculty machine anyway) and seems to cause some odd login behavior. For example, I now have two "other" entries on the login panel... bizarre!

This hint may work for users who are not command line saavy. On my faculty systems I locked down the entire utilities folder (by moving it to a separate account and creating a symbolic link to it in /Applications) so access to Terminal.app is impossible. I also removed the Managed Admin user from the 'sudoers' file as an added precaution.

I am glad to see that we have a good dicussion going; some of the ideas posted here make much more sense. I can't decide if simply removing the preference pane is a good suggestion... what happens if one of my student helpers needs to open "Network"? He has to copy it down from the server? Hmm. I am leaning toward editing /etc/authorization as soon as I figure out what it is that needs to be changed! Any advice appreciated!

Thanks for the help, everyone.



[ Reply to This | # ]
Create 'managed' admin users
Authored by: kirkmc on Mar 27, '04 03:27:43AM

Re opening preference panes - why not create an uber-admin account, and change the permissions on sensitive pref panes so only this user can open them? That way you won't have to remove them, but you will need the uber-admin account name and password to change the owner before opening them if needed.



[ Reply to This | # ]
AFP548
Authored by: JohnnyMnemonic on Mar 27, '04 01:20:20AM
The article on AFP548 that best talks about this was a little hard to find; here's the link: http://www.afp548.com/eBBS/viewtopic.php?t=956&highlight=authorization.

It's in the BBS.

[ Reply to This | # ]
AFP548
Authored by: andyinindy on Mar 27, '04 10:22:53AM

Thanks for the link! This helped a lot in deciperhing the authorization file.

So here's how this hint should have been written:

Create a new user (we'll call it "test"). Click on the limitations tab and turn off "Open all System Preferences". Now open Netinfo Manager. Select "groups", and then select the newly created "test" group. Add the "test" user as well as the other admin users to this group by adding values to the "users" property.

Now, open /etc/authorization in your favorite editor (note: this file will open with Property List Editor if you add a .plist extension to it). Edit the system.install.admin.user, system.install.root.admin, and system.install.root.user properties so that the group is "test" instead of "admin". Save the file back to /etc, being sure to remove the .plist extension if you added it.

Now login as your test user and try to install something. You should be able to authenticate using the test user's credentials. Yippee! A managed admin user done the right way!



[ Reply to This | # ]
AFP548
Authored by: marklark on Mar 29, '04 01:05:48PM

The authorization file will open in the Property List Editor if you just type 'open /etc/authorization' from the command line. :^)



[ Reply to This | # ]