Some software that I am interested in using is most easily installed using homebrew. However, my understanding from a few years ago was that homebrew requires me to give my user account write access to /usr/local. Is that still the case? If so, homebrew is not really an option for me as I rely on the traditional permissions to prevent me shooting myself in the foot.
Related
we are developing an application with a Helper Tool - which is installed into the system using SMJobBless. This works as expected; but there is a caveat.
We do frequent automatic deployments - sometimes more than one per week. Everytime the Helper Tool version changes, we re-register it - causing a password prompt. These 2 factors would quickly become irritating to our users.
Is there a way to have the password prompt appear only once, during the initial Helper Tool installation? Could subsequent updates happen without a prompt? Perhaps there is a way to leverage the existing Helper Tool to install a newer version of itself?
Short answer: No. SMJobBless() always prompts for admin credentials. There's no way to stop it from prompting. If you call this API, it'll prompt (or fail).
Longer answer on workarounds:
If your helper tool is running with admin/root privileges, it could theoretically replace itself with a new version. Think very carefully before doing this. Getting this right and maintaining security is very difficult, and the fact that even the major OSes have had vulnerabilities in installer functionality is a strong indicator that the risks of going this route may outweigh the benefits.
If you must proceed, read up on:
Race Conditions, Secure File Operations, and Time of Check vs Time of Use
Apple's Security APIs, particularly SecRequirementCreateWithString and SecCodeCheckValidity.
macOS Code Signing In Depth and the Code Signing Requirement Language
You would have to ensure that your helper tool cannot be tricked into replacing itself with (or executing) malicious code, or you will have opened your software up to being a trivial root exploit vector.
Also note: Regardless of what Apple currently does to verify helper tools installed by SMJobBless, it is conceivable that they could tighten the requirements in the future and refuse to run helper tools that have been modified since they were installed via SMJobBless. The safest method (in multiple respects) is to just call SMJobBless whenever you need to install/update the helper.
I am writing an application that when is running should modify SystemConfiguration to set system wide proxy.
I know it is possible to do that using "Authorization Services" framework provided by Apple, however I see that it keeps asking for a user password to allow changes.
On the other hand I have 3rd party application (not the one I am writing) that does the same, but does not require user password. The application is not even written in Objective-C, but written in FreePascal (FPC) instead. Unfortunately I have no source code for this application to see how it does this trick.
I know I should be able to achieve the same (system config changes without sudo password) by either having Privileged Helper Tool supplied with the application (and perhaps install it on first run) or by going even nastier and loading a kext.
However I see that this application does neither of above. It only performs system calls and no password asked! I am completely puzzled how did they achieve that and would like to find a way to do the same.
So the question is - how to achieve complete "no password asked" for changing System Configuration on Mac OS X with an application?
PS: Application I have at hand runs as user, not root. And there is no modifications to sudoers neither.
This is silly, but after 2 days straight of searching for a solution I found that there is no special code nor any tricks required.
This is easily done via setting setuid bit to binary that requires escalated privilege and calling setuid(0) in the code before doing operations that require privilege (not sure if second part is necessary).
Relevant links:
Apple documentation
Related question on SO
PS: This works basically on any Unix-like system (BSD, Linux Solaris etc) with one details - this does not work on scripts (the ones that require hash-bang #! in order to execute interpreter) with exception of Solaris, where it seems to work just fine.
The problem is that recently on my company we need to make an installer, since anyone haven't worked with InstallShield Before we have a lot of questions about it.
So here are the questions:
Am I able to restore a database using InstallShield? I mean, giving to it the path of the .bak file and then run a script and recover the database on mssql?
Does Install Shield have configuration files, so I'm able to change the files that are going to be used, depending on the client and the software version we are installing? Nowadays we use our own setup, but we have to select the files manually, so when a client whants to install a software we have to go with them and do it, because is really complex. Now we need to change that by making an installer that can be configured here in our company by and IT member, then send the files and the installer to the client and he only press "Next, Next..."
Sorry for my bad english
You might find that treating the front-end software and database as two separate items is easier for you and your clients. While many vendors offer the ability to run scripts against SQL Server (and other databases) during the course of the installation, you'll find that there are all kinds of issues you need to contend with (do you need to first install SQL Server, does the user have permission to access the SQL Server, what if they are installing the software on a new pc but don't need the database created again, etc). None of these are showstoppers, but they do create headaches that you need to deal with.
By treating the database and front-end separately, you can build an installation package that installs your front-end software and related components on the target machine. This in and of itself can be tricky to deal with depending upon how complex your software is and the amount of references and prerequisites you need to manage.
When it comes time to manage the database aspect of the program, you may find that the majority of your clients are capable of restoring a .bak file to their SQL Server, and the ones that aren't can always be assisted (probably remotely) by your staff.
If you discover that this isn't the case, you can always create a separate "Server" installation package that manages the database aspect of the installation.
With regards to your question about InstallShield, you'll probably find better information from their website and \ or sales staff, but here's a list of their current features.
There are other vendors in the space as well, so look at all of them including InstallAware and my personal favorite Advanced Installer. Pick the one in your budget that offers the features you need. They all should offer trials as well. Download and use them before you buy to find one that works best for you.
Yes installshield can call a script that will restore a db, you just need
to do so in silent mode. and yes there is a cfg file for install shield.
the documentation will show this in detail
here is some documentation for version 12
http://kb.flexerasoftware.com/doc/Helpnet/installs hield12helplib/IHelpContents.htm
they are currently on version 2012, however if you are doing this
crossplatform, don't use installshield, but use installanywhere. it is cross
platform.
I have an existing application working on DNN 4.3. I am planning to write another application using DNN 6.2. I want to share user infromation between these two instances.
Is importing user data my only option or is there a better way of doing this.
Almost surely using the Datasprings Interactive User Import tool will be the best option. This option is preferred if you can get by with syncing either once, or at intervals larger than a week.
A second option is to verify that both web.configs have the same machinekey and to sync your user-authentication-system tables in a more manual fashion. I'm not sure if the user-authentication-system tables have changed between version 4.3 and version 6.2; I'd wager that they've changed a little and that you will have to build a manual syncing tool. DotNetNuke has its own UAC tables that ride in parallel to the standard ASP.NET UAC tables. Both will have to be synced if you go this route. This option will likely require a serious bit of research and development.
Is this sort of thing that would be of use?
"Cross Portal Authentication: If a user attempts to login that belongs to another portal but not in the current portal then they are automatically registered to the current portal and logged in."
If so then see OnyakTech LogIn. It will take a bit of work to set up, however the developer provides good support. Worth investigating to see if its of use.
A lot of my programs require the ability to write files to the hard drive. When I first made these programs for XP they worked great. Now I'm less ignorant about UAC (got a new laptop recently). And for future customers...I've noticed the potential for a LOT of annoying error messages....and quite frankly if the program can't write data to the hard drive or thumb drive it's on...there's no point to running it....
I've tried multiple times to build in the manifest a requirement for administrator or user access....I'm not sure if anything less would solve the problem...but have failed because click-once has security features in place to prevent me from doing so.
I'd rather not have to tell my customers how to make the program run as an administrator by editing the file's properties...I'd much rather have a convenient pop up like what you'd see new programs such as Itunes or Filezilla show if they were in conflict with UAC requesting the privileges they need.
I'd really like to do this but have had little success.
Any and all advice that can remedy this grievous problem appreciated.
Thanks.
First, let me tell you that the design goal of ClickOnce deployment is not to require administrative privileges. This translates into "you can't elevate privileges when running a ClickOnce application".
When Windows Vista came out, Microsoft published guidelines on where to store files that you want to be able to update. NOTHING should be placed in Program Files; they generally recommend LocalApplicationData or Isolated Storage. The same issues are in place for Windows 7.
So where are you trying to write data for your customer?