I have noticed that some applications after installation open a window and ask for user's password. It says that the application needs system.privilege.admin. I was trying to figure out what exactly this means. The application itself seems to be running in user mode. Then why does it ask for the password? Can anyone please help?
Most Mac installations put the program into the Applications folder. By default this is not writable to users. Under the hood the installer is basically doing a sudo so that it can write the files to Applications.
In addition many mac apps have a preferences file in the system library. This will aso require admin privilege to write.
Finally, the application may register what kinds of files it can open. E.g. pdf files can be opened by Preview or Acrobat Reader, or Acrobat distiller. The system needs to keep track of which apps can do what.
Related
I have a windows application getting ported for Mac.In windows i store encrypted data in the registry.But when it comes to Mac im unfamiliar.
The application is licensed per PC.So all Users using the Machine will be able to use it.So in windows im storing the key in HKEY\LOCAL MACHINE
How does user access rights work in Mac? Where do i need to store the data?
This type of data is usually stored in a file in Application Support directory. If you want to store one file for all users you should choose /Library/Application Support system directory.
The directory is not user-writable, so you will have to run installer with root privileges. This directory can't be used by sandboxed apps.
You should create a subfolder in this directory and store your file inside.
For more information see The Mac Application Environment, especially Table 1-1, "Key directories for Mac apps", and File System Basics.
Edit:
Usually OS X apps don't need any installation. They are self-contained bundles that can be run from any location. Usually you keep them in Applications folder (drag it there). System wide /Applications folder is accessible for all users. There is also private ~/Applications folder in each user's home.
On the other hand apps that need to install data to system folders use installers. Installer usually copies application bundle to /Applications folder, but also handles authentication and asks user for admin credentials. Installers may also run scripts.
Maybe your license could be generated by a script during installation?
If not, you would have to generate license file on first application run. In such case, if you want to keep one file for all users in /Library/Application Support, you will have to escalate privileges and ask user for admin access. If you don't want to do that, consider storing separate license file for each user in their home ~/Library/Application Support folder.
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
I want to deploy a dmg on Mac OSX and higher. It should not need admin privileges to install the application to the application folder of the system. Is this possible?
Thanks in advance. :)
I don't think dmg is the word you are looking for. If it is an app, you can typically just drag the app to the Applications folder.
If you're trying to install something that requires admin privileges and you are physically at the computer, you will need to boot into single user mode with Command-S. From single user mode, you are the root user and can do whatever you choose.
I made a small application and installation package for the application with installshield LE designed for Windows Xp/Windows7 32bit.
Everything is working ok but i have premission issues.
First of all, if user is not administrator then he cant install the installation package.
(In the Require administrative privileges i entered "No") - This issue is OS or installation package restriction ?
So.. I went to XP and logged in as normal user, i launched the installation and it elevated me to be admin. then I entered an admin password in order to continue the installation. afterwards everything went fine. now i cant start the application - only as administrator.
Why is that? how can i do that the user can run the application ?
it cant write the logs file (which my application writes) to the program files folder.. no premissions..
How can i handle this ? If a certain user installed the application i want him to be able to do anything with it. only the installation itself require admin log in.
Thanks
The Program Files folder is a very special directory. Only admins are supposed to make changes to that. If your installation writes logs to Program Files, it is just wrong.
If you need a normal user to install and interact with your application, you should create an application and an installer suited for STANDARD USER. Such an installer will not write anything into Program Files.
Have a look at this:
http://blogs.msdn.com/b/rflaming/archive/2006/09/30/778690.aspx
Is there any way to allow non-Administrator users to install, upgrade or uninstall an Adobe AIR application on Windows?
I've made an Adobe AIR application and packaged it as a .air package using the standard AIR mechanism for creating deployment packages. If a normal or Power user tries to install this AIR application, the Application Event Log shows an error saying administrative rights are required. And even if the user elevates during installation, administrative rights are still required for an upgrade using the automated AIR upgrade system (since an upgrade is essentially, behind the scenes, an uninstallation of a .msi package followed by an installation of another .msi package).
Is there any way around this?
What I've tried so far is:
Using the Group Policy editor, setting Windows Installer to elevate during installations. Doesn't work, since AIR attempts a "for all users" installation.
Specifying My Documents as the installation directory. Doesn't work, since AIR attempts a "for all users" installation.
Giving the user Modify access to the Program Files folder where the application would usually reside. Doesn't work, since this isn't a file permissions issue.
Making the user a Power User. Doesn't work, since AIR attempts a "for all users" installation.
I'm guessing that both installing and upgrading would work fine for a user if
the AIR installer would attempt to make an "only for me" application installation instead of a "for all users" installation, and
the user was a Power User, and possibly
the application was installed to My Documents
I'm also guessing that this problem doesn't exist on OSX and Linux, since they have more intuitive concepts for per-user application installations.
EDIT: As of Adobe AIR 3, you can use a "captive runtime" to avoid the administrator install of AIR. See the descriptions here and here. Disclaimer -- I haven't actually tried this.
ORIGINAL answer for pre-AIR 3:
There does not appear to be any way to work around this according to the AIR 1.5 Administrator's Guide section on installing apps, which states:
On Mac OS, to install or update an AIR application, the user needs to have adequate system privileges to install to the application directory (and administrative privileges if the application needs to update the runtime). On Windows, a user needs to have administrative privileges.
So this limitation apparently applies to all supported OSs. The tone of the document throughout makes it quite clear that AIR is designed to assure system admins that users will be appropriately locked down. AIR is not the happy pathway from browser to desktop that I'd hoped.
This description of using the Air SDK to run the application might work on windows, too: http://agoln.net/archives/106
Not sure how that interacts with auto-update...