Script for providing access to non-admin users to update any softwares

I'm thinking Self Service is your friend, but perhaps you have reasons for not going that route. Can you give some background?

@kumar
I would agree with jared's idea about Self Service.

Um, yeah, Self Service is designed exactly for this purpose. Unless what you;re really asking is for a way for non admin users to utilize the existing built in update process in certain applications. If so, if you're talking about an app, like Software Update or Microsoft Auto Update, etc. those can be run with root privileges out of Self Service, which would remove any need for a password to be entered by them. They'd basically be "launchers" from Self Service instead of actual installers. But it works.

Hi All,

Thanks for the reply, but the issue is not with the installation but with the updates, I have few app that will get updates every week and for updates application prompts for admin user name and password which I want to eliminate at non-admin user level.

@mm2270 how do we do an dmg or pkg or .app as an application launcher in self-service?

Regards,
Anil

@Kumar It would help if you list the applications you're concerned about.

@Don, Sorry I can disclose the application name but any .app application in /Applications folder is asking for admin user name and password.

3 solutions:

1. Disable auto-updating within those apps, package the updates, push them out or advertise in self service
2. Give admin rights
3. Muck with /etc/authorization to give additional rights to standard users. Be insanely careful.

There is no script to magically circumvent OS X's security model.

@kumar You'll find as @jarednichols stated there are different ways to handle these things, so you really will need to provide application names. Some applications can be managed using defaults, or you may need to capture/push config files, some will require file/folder permission "adjustments" that can break when the next patch comes out...etc.

If you're expecting a quick, catch-all solution that will "fix" the issue(s) across the board, well, in the words of Computer Scientist Dan Shoop, "That's woolly thinking". :)

Don

Further to Don's comment: it is usually possible to disable auto-updating for most applications that support auto-updates. Unfortunately, the method of disabling auto-update is app-specific. Even for those apps that use the popular Sparkle framework to provide auto-update capabilities -- you can't disable Sparkle updates across the board; instead you must specifically disable autoupdates for each app that uses Sparkle. In this case, it can be done with MCX or Profiles, but other apps (like Google Chrome) require other methods.

Auto-updating apps are nice for home users, but not so great for enterprise or edu environments.

Just to chime in again, I agree with all the above comments. If you are looking to allow your users to upgrade their own apps, why not just consider making them full local admins? And then also be prepared to deal with some of the consequences that brings. There are pluses and minuses to the approach. Most here shudder with the thought of the users they managed being admins, but in some environments its almost a necessity. Others are the complete opposite.

As Don points out, unless you can provide some applications that you are looking to allow updating or perhaps shut off the auto update mechanism, you won't find much of a resolution. The only consistency about it is its inconsistency, as Greg pointed out.

Otherwise, just package up the updates and place them in Self Service for users to run at their convenience.

Editing /etc/authorization (as per Jared's comment) is also an option to allow some controls for installing apps or updates but not making them full admins, but the process is involved and you need to test it VERY thoroughly.

To answer your question though about the "launcher" method I was referring to, you could for example, make a Self Service policy that opens Software Update with root privileges for the user running it, removing the need to enter a password to install anything. However, I have a strong suspicion this method breaks in Mountain Lion. 10.8's sandboxing and security is much more strict and may not allow it, at least not without doing something like creating a user level LaunchAgent that triggers it.

Hi All,

Thanks for your reply, but the issue is that I can't provided admin access to all the users, I have almost 600+ users for whom we need to enter the admin user name and password when ever there are updates and I have given permission to /Applications and /Library it works but it is same as I am giving admin access to users which is agains the Info sec policies.

I have even edited the /etc/authorization file but standard user are not able to log after changes made, linked followed (http://mattsmacblog.wordpress.com/2011/07/30/mac-os-x-10-7-lion-first-look-at-etcauthorization-usage/)

Thanks,
Anil

As Don points out, unless you can provide some applications that you are looking to allow updating or perhaps shut off the auto update mechanism, you won't find much of a resolution. The only consistency about it is its inconsistency, as Greg pointed out.

There's always Staples...

external image link

Seems to me that the solution is to disable auto-updates & then push them out when they're issued. If you can't disclose the name of the app in question, then you should contact the vendor and ask them how to do it.

As for the updates, you could use login/logout hooks to push the updates without interrupting the user's workflow. We do several things this way, only forcing the issue on those users who insist on never logging out. ;-)

Yup. Talk to your top secret app vendor and ask them to provide a solution to disable to update notifications then push your updates via Casper.