Most newer programs will have the options to either Install for the Current User or Install for All Users. If the current user is selected, whether you can use the program with a new user account depends on the folder locations and registry locations where the program installs it's files. Here is one thing you can try. Aug 11, 2014 Whether your IT department locked down your Mac or you grabbed one from eBay that the seller forgot to “clean up”, you may encounter a big problem when trying to install software as a non-admin. Here’s a possible workaround. If you’re trying to install software on your Mac the first thing you should do is simply contact your IT department.
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.
This was tested on Mac OS X 10.10 and 10.11 (see below) Right-click on the folder you want to see (In Finder) Click Get Info in the drop-down list that occurs; Click the lock in the bottom-right corner; Authenticate; Under Sharing and Permissions click + Add your own username (or a group, like Administrators) with Read (or Read/Write) permissions.
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.
'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.
Ouch.
'I love how every apple application has a BASH command for it.'
That's not even close to being true.
The thought of my 2000 users updating their own software via the terminal scares the crap out of me...
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...
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.
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.
Stop thinking like a server admin. Trashing your home files is non-trivial and running non-admin does nothing to prevent that.
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.
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.
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.
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.
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.
I've got three words for this. 'Really', 'really', and 'dumb'.
So you're already adding a crontab entry? Why not add it as root, so no sudoing will be needed at all?
Fairly,
Would appreciate if you have a more professional way of doing this.
or is it just that you are dumber than me.
Would appreciate if you have a more professional way of doing this.
or is it just that you are dumber than me.
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.
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.
Mac Allow Users To Install Software Download
Apple has introduced a number of features designed to protect users from malware in OS X, but these tools occasionally go too far when trying to save people from themselves.
TL;DR:If you have an app from an unidentified developer and you're sure the app is safe, you can force it to run by right clicking (or command-clicking) the app and choosing 'Open' from the context menu.
OS X's Gatekeeper feature — introduced with OS X Mountain Lion — places restrictions on which apps can be run on a Mac based on the avenue through which the apps were acquired. There are three tiers: apps which are distributed by registered developers through the Mac App Store, apps which are distributed by registered developers outside of the Mac App Store, and apps which are not made by registered developers.
Gatekeeper distinguishes between the latter two based, broadly, on whether the app has been signed with a legitimate Apple-issued signing key.
By default, Gatekeeper is configured to allow apps from the Mac App Store and from registered developers. Users can make this more or less strict:
- Open System Preferences
- Open the 'Security & Privacy' pane
- Select the 'General' tab
- Click the lock icon in the lower-left corner and enter an administrative username and password
- Select one of the three available levels under 'Allow apps downloaded from:' and close the preference pane
Unless you choose to allow apps downloaded from anywhere, OS X will warn you against opening apps that aren't signed: you'll see a dialog box that says ' can't be opened because it is from an unidentified developer,' and clicking OK will simply close the dialog.
Install App On Mac
If you're sure the app is safe, you don't need to alter your security preferences to open it — there's a faster workaround.
Right click (or command-click) on the app and select 'Open' from the context menu. This will present a slightly different dialog box: this time, you'll be presented with an 'Open' button that will let you force OS X to run the app.
![Mac Allow Users To Install Software Mac Allow Users To Install Software](/uploads/1/2/6/3/126320052/658000066.png)
Remember: only do this if you're sure the app is from a reputable developer and has not been tampered with.
![Mac Allow Users To Install Software Mac Allow Users To Install Software](/uploads/1/2/6/3/126320052/643409455.jpeg)
AppleInsider has affiliate partnerships and may earn commission on products purchased through affiliate links. These partnerships do not influence our editorial content.