I'm making an OS X Installer package. I download it from a build machine onto a test machine (10.5.8) and then run it. In the console, the following message is immediately logged:
kernel[0]: Finder[52646] Unable to clear quarantine '<package name>': 30
From what I've read, Leopard sets a quarantine extended attribute on all downloaded files. It's possible to use xattr to remove that flag, although that obviously doesn't apply to this situation, since a program can't un-quarantine itself.
I don't have a problem with the quarantine itself, or with Leopard popping up some dialog asking whether the user trusts the program. But I would like to know why the quarantine could not be cleared, and whether there is a way to modify my installer or the scripts it runs to prevent that error from being logged.
Does the user on the test machine have administrative privileges? If the app is in a folder such as /Applications, you'll need them. If you can not change the user, try to download the app in his home folder.
I'm guessing you downloaded it as a privileged user but you're running the installer as another user. Since the file is owned by the user that downloaded it, the user that wants to run it can only do so read-only. Check the file ownership and permissions to see if i'm right.
Try to copy from your build server using ditto (and pay attention on various switches that control the copy src and dst)
check access rights on the share of your build server
Related
I've written a Win32 program that at regular intervals retrieves content from a dedicated server on the internet.
Sometimes the Win32 program itself needs to be updated. What I do is exit the said program and run a download-program which replaces the main exe I need to uopdate. This works for users running in Administrator mode but not other mode that has sufficent rights for most tasks. The program runs on it own directory which is not under "c:\Windows\program files\".
I've set a manifest file to no avail.
Is there a workable workaround solution for this (any)?
For security reasons you cannot place files in Program Files without admin rights. If you would be able to this you could in theory change Windows files and place malware as well.
Same goes for Linux and OSX systems.
However you could prompt the user for an Administrator password and gain the admin rights in that way.
You need your updater program to have admin rights. You achieve that by adding the requireAdministrator option in the requestedExecutionLevel section of the application manifest. You said that you have tried this to no avail. Well, you must have got something wrong because this is the solution. You just need to persevere until you get the manifest correct.
I presume that when you say that the [program is not under the Program Files directory you refer to the updater. If the program being updated is not under the Program Files directory then there would seem to be no obvious reason that the updater needs admin rights. If that is so then you need to investigate further.
I have a small diagnostic OSX program - a small menu-tray app - that I need to get to a customer. The program makes use of dtrace. As such, it has an auxiliary executable in it's MacOS directory with its suid bit set and ownership set to root:wheel. The helper's only role is to immediately exec() to dtrace with an included dtrace script.
My problem is that I can't figure out a good way to get this to the customer. Naively putting it into a .zip archive wiped out all the special permissions.
When I tried to put it in a DMG, the root:wheel ownership got reset to mine (ted:staff). I found that I was supposed to use diskutil to enableOwnership on the DMG to get it to start respecting file object ownership settings. So now I can see that inside the DMG, my helper program has the required root:wheel and +s suid permissions set.
Now, however, I've found that when I drag and drop the app bundle out of the DMG and onto the desktop, the permissions get reset again. Moreover, when I try to run the application from the DMG, it behaves as though the helper program doesn't have the suid bit set.
Stepping back from this a bit, I don't see why this should work at all. It seems like it would be a nasty and really obvious security hole to allow developers to distribute app bundles with the suid bit set like this.
So how is this done at all? Do I need a package installer? Will that preserve the suid bit? Can someone school me on how this is supposed to work?
You are correct that (if there were a simple way to do this) it would be a nasty security hole. You should never be able to create/install a setuid root executable without going through some admin authorization step. Indeed, you shouldn't even be able to create/install a file with ownership set to any user other than your own.
(Actually, there is an exception to that in 10.9: the App Store will allow you to install apps without admin rights. But that's considered relatively safe because Apple vets the apps before they're allowed in the store.)
The "right" way to do this is with a package installer. It can be set to request admin authorization for the installation, and use that to install files with whatever ownership and permissions you want (including the setuid bit).
Perhaps using a .tar file would work. They are very good for keeping all of the UNIX specific baggage like ownership attached to folders and files inside of them.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I have a daemon that needs to run as root and is started by launchd. This daemon needs to store some user supplied credentials so I have it writing them to the System keychain using SecKeychainOpen and similar functions.
I'm pretty sure that since this runs as root I have to use the System keychain (since using a user's login keychain is not correct as this doesn't run as a normal user).
My installer loads this into launchd using launchctl at the end of the install. The problem is that it doesn't actually start until after a reboot. I had OnLOad set as true in the plist, but it appears that when using the system keychain I need to the reboot for it to work.
I was wondering if anyone knows of some way to deal with this since it would be a much better user experience if a reboot was not necessary. So to be clear, can I programatically access the System keychain from a daemon using launchd without a reboot?
Thanks for any advice or ideas.
Since I eventually figured out that my problem wasn't what I thought it was at all, I figure I should put the resolution to it up here.
It turns out (despite what I read on a few sites) that it is perfectly OK to programatically access the System keychain with a daemon using launchd without a reboot. Just load the plist in the normal way (with root permission of course) and it all works.
My issue was the my postinstall script was never being run and was actually never even included in my .pkg installer when building on certain macs. Apparently, if you do not have PackageMaker.app installed, macports will still make a dmg with an installer for you, but the installer is a directory rather than the proper single file and it may lack certain parts (such as my postinstall script).
PackageMaker.app can be found on the Apple Developer site in the Xcode AuxTools package (it then needs to be put in either /Applications or somewhere else macports can find it).
My installer installs the app to "Program files\MyApp", the app when running changes files within this location. On Vista, by default this brings up UAC issues.
I want users to be able to run MyApp without being admisn or fighting the UAC screen everytime they run the app. If they have to get through UAC to install the app, that's OK though still not optimal.
I thought I had this set up, but it's not working:
[Setup]
PrivilegesRequired=admin
AppName=My App
AppVerName=My App 1.0
DefaultDirName={pf}\MyApp
DefaultGroupName=MyApp
UninstallDisplayIcon={app}\bin\MyApp.ico
OutputDir=..\Installer
ChangesAssociations=yes
[Dirs]
Name: "{app}\"; Permissions: everyone-modify
Name: "{app}\redist"; Flags: deleteafterinstall;
Specifically I thought Name: "{app}\"; Permissions: everyone-modify would let normal users run it, removing UAC protection on Program Files\MyApp.
I am picking at values a bit by random, can anyone suggest some changes? Again, the aim is that once installed, normal users in non-admin accounts can run it even though files are saved in Program Files, without UAC kicking in. As a secondary thing, the installation itself should not be too crazy... a single prompt for admin password or UAC authorization.
Don't install under {pf}. Instead, install to a user-writeable location (for instance, {localappdata}).
http://www.kinook.com/blog/?p=53
You should change your app so that is saves shared data in some other folder.
Granting write permissions for any user to a folder in PF that contains executable code (exe,dll's etc) is a security issue (Evil user could modify exe file and wait for admin to run it)
Alernativly you could store the files in a subfolder in PF and only grant write access to it, that way your executables are safe.