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


Click here to return to the 'Allow non-admin users to run Software Update' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Allow non-admin users to run Software Update
Authored by: sapridyne on Sep 10, '07 07:58:01PM

The thought of my 2000 users updating their own software via the terminal scares the crap out of me...



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: rgray on Sep 11, '07 07:25:52AM
Agreed... Doesn't this hint blur the distinction between admin and non-admin users? The idea of letting my lab users update for themselves produces chills and tremors..... If you are going to let users do admin stuff and can trust them to do so, then why not just give them admin status. Here we protect admin status like it was the Holy Grail...

[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: rogov on Sep 11, '07 09:39:31AM

Apple already blurred the distinction which is the real problem.

Normal, everyday typical user activity should normally not need admin privileges. Yet, Apple doesn't deter this and most OS X home users run in admin accounts. While not as bad as running as root, it is still a questionable idea which some would call 'defective-by-design'.

It takes a lot less effort to totally screw over a computer because of this. For example, not long ago there were reported security issues with running a standard OS X .pkg installer in an admin account. I believe it was possible to execute a shell script on launch without requiring permission to run first. Under a regular user account, the destruction would be limited to user files, but the admin account gives you access to a lot more things.

Now did you know that the 'diskutil resizeVolume' on Intel Macs doesn't require any authentication if you are in an admin account? You can invoke the tool and it will dutifully try to resize your partition. The tool itself is not very well documented and I suspect it has not been exhaustively tested under many conditions, due to the new-ness of the utility and considering Boot Camp is still beta. I would wager there are some nasty bugs hiding in the tool or HFS+ itself that could be used to totally trash a partition.

Now imagine combining the following in an admin account:
1) A web site that automatically downloads a .pkg when you arrive.
2) Safari considers it a 'safe' download and automatically launches.
3) The old .pkg behavior that runs a script behind your back without requesting permission first.

(Or simply substitute 1-3 with your typical buffer overflow exploit which is used to execute a script.)

4) Run 'diskutil resizeVolume' in some really nasty way that will screw up your partitions. (Or just confuse the hell out of the user by shrinking their boot partition to the point where they get nag messages that they are almost out of disk space.)


Obviously there is a large chain of questionable things in this list. I don't think diskutil resizeVolume should work without further authentication. But yet that's the current behavior. I don't think Safari should automatically open 'safe' documents, but that's the default. (I can't remember if .pkg is considered safe or not, but even if it's not, Apple could change it in the future.) But a Safari buffer exploit could get around this problem. Not running as admin would be your last line of defense in this scenario (unless diskutil lets you run even as non-admin which now that I think about it, it might).

But the greater point is that running as admin when you don't need it leaves you more vulnerable to attack than you really needed to be.


Some defensive users disable admin access for their normal everyday user account and create a separate admin account. However, because they rarely do admin things, they rarely login to the admin account. Since you can't tell Software Update to automatically run periodically to check for updates in a non-admin account (actually you can tell it to, but it ignores you), it's really easy to forget to do software updates. This is also bad. So allowing people to designate that Software Update is available to non-admin accounts is very useful.

In your IT case where you have dozens/hundreds/thousands of users, yeah, you probably don't want to let your users invoke software update. So don't use this hint. But for home users that have separated their admin accounts from their user accounts, this is a very welcome hint. I suspect you could also modify this hint to single out specific users if you did have to worry about both classes.







[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: frgough on Sep 11, '07 10:06:27AM

Stop thinking like a server admin. Trashing your home files is non-trivial and running non-admin does nothing to prevent that.



[ Reply to This | # ]