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

Allow non-admin users to run Software Update System
Software Update has a 'quirk' in which non-admin users will never get prompted to install updates, even if the administrator sets them automatically download. So the problem is that if you have multiple machines in a mostly unmanaged environment, updates only occur if an admin logs in or if users run Software Update manually, and in either case the process must be authenticated with an admin password

But partially no more! If you edit the sudoers file, you can allow the CLI version of Software Update (i.e. softwareupdate) to be executed by your users.
  1. Edit the sudoers file /etc/sudoers. Use the command sudo visudo; this will drop you into the default visual editor (usually vim).
  2. Add ALL ALL= NOPASSWD: /usr/sbin/softwareupdate to the file. Placing it at the bottom is OK. Be sure to add comments on your change by using # as the first character. Do not comment out the actual sudoers directive you just added, however. Save and exit the editor.
  3. Run softwareupdate -ia from Terminal in a non-admin user (any) account and watch the show.
WARNING:
I don't think this action will prompt for a restart, so the system will be running in an indeterminate state. Be sure to restart right away if you are trying this on a reboot-needed update. You have been warned.

Real world uses
With this hurdle covered, you can now add a cron/launchd job to download updates for sure (softwareupdate -d). I have been thinking about seeing if I can work this into the logouthook function. If so, then shutdown -r now will also need to be in sudoers. It has also been suggested to use an osascript command to issue a Finder restart to allow users the normal warnings.
    •    
  • Currently 2.83 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (6 votes cast)
 
[22,450 views]  

Allow non-admin users to run Software Update | 13 comments | Create New Account
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: tom larkin on Sep 10, '07 01:33:10PM

Nice hint, but too bad we don't let our users access the terminal. I love how every apple application has a BASH command for it.



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: Fairly on Sep 13, '07 06:14:21AM

"too bad we don't let our users access the terminal"

Ouch.

"I love how every apple application has a BASH command for it."

That's not even close to being true.



[ Reply to This | # ]
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 | # ]
Allow non-admin users to run Software Update
Authored by: talkrhubarb on Sep 11, '07 04:31:10AM

I don't run my home mac as an admin user, and wondered why I always had to run software update manually. Thanks for this.



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: Tezzaaust on Sep 12, '07 06:09:45PM

I have added the command to /etc/sudoers
I have created a crontab with a pop up downloading and downloaded users warning. (10 mins set for testing only)

0,10,20,30,40,50 * * * * open /Applications/updating.rtf ; open /Applications/Utilities/terminal.app ; sudo softwareupdate -ia ; open /Applications/updated.rtf

Unfortunately this crontab command works from a terminal window but not from the crontab even though the crontab opens a terminal window and shows both warnings but seem to skip the softwareupdate -ia command
Anyone know why.



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: MrLint on Sep 17, '07 06:34:43PM

Tezzaaust:

I think your problem is that you are (I think) trying to inject the softwareupdate -ia into the terminal window via a separate command, which really wont work. I would suggest you make, and save yourself a .command file with the command in it and then call that form your cron job.



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: Fairly on Sep 13, '07 06:12:32AM

I've got three words for this. "Really", "really", and "dumb".



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: zottel on Sep 13, '07 03:41:32PM

So you're already adding a crontab entry? Why not add it as root, so no sudoing will be needed at all?



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: Tezzaaust on Sep 13, '07 07:01:26PM

Fairly,

Would appreciate if you have a more professional way of doing this.
or is it just that you are dumber than me.



[ Reply to This | # ]
Allow non-admin users to run Software Update
Authored by: MrLint on Sep 17, '07 06:31:24PM

Ok well a bit more research on my part has lead me to the determination that while my original tip is interesting, not quite what I needed.

If I were to add softwareupdate -ia to /etc/rc.shutdown.local this really gets me to the solution I was looking for. Making sure the clients get update even if OS X wont let them do so manually.

The result will give a 'hang' on system shutdown during which its downloading and installing updates. But at least it works.



[ Reply to This | # ]