This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallAnywhere
- :
- InstallAnywhere Forum
- :
- Re: IA2010, MacOSX and sudo launchctl
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 17, 2012
03:42 AM
IA2010, MacOSX and sudo launchctl
Hello,
With IA2010 I'm trying to install a daemon on a Mac.
so,
1) In IA, Project, Platforms, MacOSX,
I Checked the 'Requires an administrator Name and password to install' box, so as to run the installer as root.
2) I provided the installer with 2 shell script files:
- one to copy the 'application.plist' to /Library/LaunchDaemons and set proper rights.
- one to run 'launchctl load...'
everything is run without 'sudo' since the installer is supposed to run as root.
but it does not work...no error message can be seen in the console !!!
I run the scripts using actions 'execute command' or 'execute bat/script'.
3) If I run the scripts in a terminal with sudo, it works fine
4) if I include 'sudo' in the shell scripts, I receive error messages in the console (no tty and no askpass...) and the job is not performed.
I'm stuck here...
How to install and launch a daemon on a Mac with IA ?
Thank you and kind regards.
Alain
With IA2010 I'm trying to install a daemon on a Mac.
so,
1) In IA, Project, Platforms, MacOSX,
I Checked the 'Requires an administrator Name and password to install' box, so as to run the installer as root.
2) I provided the installer with 2 shell script files:
- one to copy the 'application.plist' to /Library/LaunchDaemons and set proper rights.
- one to run 'launchctl load...'
everything is run without 'sudo' since the installer is supposed to run as root.
but it does not work...no error message can be seen in the console !!!
I run the scripts using actions 'execute command' or 'execute bat/script'.
3) If I run the scripts in a terminal with sudo, it works fine
4) if I include 'sudo' in the shell scripts, I receive error messages in the console (no tty and no askpass...) and the job is not performed.
I'm stuck here...
How to install and launch a daemon on a Mac with IA ?
Thank you and kind regards.
Alain
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2012
09:42 AM
Had similar problems, in fact when you "become root" in InstallAnywhere you don't really become root.
You become "effective UID root" while your "real UID" is still whatever it was before (but not root), which is what happens when you run a "setuid program".
This is Unix stuff, if you want more explanation you can google "real and effective UID unix", there are a lot of articles about this subject 🙂
The bottom line is: you're almost "root", but not completely, and while it's enough for, say, copying files into the system, some commands ("sudo" in particular) see the difference.
To solve this, you can either modify the InstallAnywhere setup to inject a little C program which does a "setuid(0);", which turns your program into a real root program. That's what I had to do and it's quite complicated 😕
Another, easier, trick is to use the same technique (a C program which becomes root), but use it in front of each command and script you run from InstallAnywhere. Here's a program which works, let's call it "fix_uid":
Note that this is NOT a security risk. "setuid(0)" only works when you're already root, that is, you have the setuid set. The security risk lies in the program which started "fix_uid", and in our case, it's InstallAnywhere, which is (thanks to its own authentication mechanism) setuid root.
(Gosh, I hope it's not too unclear...)
Anyway, once you have this program, you use it to prefix your commands. For instance, instead of writing:
you write:
Hope this helps.
You become "effective UID root" while your "real UID" is still whatever it was before (but not root), which is what happens when you run a "setuid program".
This is Unix stuff, if you want more explanation you can google "real and effective UID unix", there are a lot of articles about this subject 🙂
The bottom line is: you're almost "root", but not completely, and while it's enough for, say, copying files into the system, some commands ("sudo" in particular) see the difference.
To solve this, you can either modify the InstallAnywhere setup to inject a little C program which does a "setuid(0);", which turns your program into a real root program. That's what I had to do and it's quite complicated 😕
Another, easier, trick is to use the same technique (a C program which becomes root), but use it in front of each command and script you run from InstallAnywhere. Here's a program which works, let's call it "fix_uid":
#include
#include
#include
int main(int argc,char *argv[])
{
setuid(0);
printf("\nFIX_UID\n"); system("id"); printf("\n");
execv("/bin/sh",argv);
}
Note that this is NOT a security risk. "setuid(0)" only works when you're already root, that is, you have the setuid set. The security risk lies in the program which started "fix_uid", and in our case, it's InstallAnywhere, which is (thanks to its own authentication mechanism) setuid root.
(Gosh, I hope it's not too unclear...)
Anyway, once you have this program, you use it to prefix your commands. For instance, instead of writing:
launchctl -c ...
you write:
{path to fix_uid}/fix_uid -c "launchctl -c ..."
Hope this helps.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 19, 2012
05:56 AM
Thank you Weelyn for your answer.
Its perfectly clear, and I think your solution is good.
During this time and to sort this problem out,
I considered this kind of installation procedure as targeted to an administrator.
So I prepared a 'handy' script to do the whole stuff and asked the Administrator to launch it himself (with the full root privileges).
Its perfectly clear, and I think your solution is good.
During this time and to sort this problem out,
I considered this kind of installation procedure as targeted to an administrator.
So I prepared a 'handy' script to do the whole stuff and asked the Administrator to launch it himself (with the full root privileges).