2 Ways To Install Software On Windows Without Admin Access. Method 1 To Install Software Without Admin Access. This is not a sure shot method, as there are equal chances of it letting you install programs and stopping you form the same. Below are the steps: Restart your computer; While it begins to boot, hold the F8 key and select the Safe Mode. Dec 01, 2016 No regular app or game should ask you for administrator privileges just to do a simple install on a Mac. With this procedure you can securely install your apps without giving them your password.
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 |
Python Install Without Admin Rights
- Setting an administrator account apart is its elevated privilege levels. Administrators can change system preferences that control how the Mac works and feels, install software, and perform many special tasks that standard user accounts aren’t allowed to perform.
- This answer is not a 'Mac' answer, it's a general Unix answer which 'might' work for certain programs under OS/X: If it's open-source, just compile the source under your own user directory in Terminal. If 'make install' fails due to lack of administrative privilege, simply run the executable from its location.
- How to Allow Users to Install Software without Admin Rights in Windows 10. An admin account on a Windows PC enjoys more privileges than any other account types. This account can install apps and make modifications to the system easily without too many steps.
The following comments are owned by whoever posted them. This site is not responsible for what they say.
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'.
Admin Rights Windows 10
![Rights Rights](/uploads/1/2/6/2/126243980/141132696.jpg)
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.
Windows Xp Admin Rights
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.