how to open a app as root with terminal
- Thread starter taewon
- Start date
gumse
Member
sudo -u ausername open -a /Applications/Calculator.app
Should work, but I just get a load of errors:
kCGErrorIllegalArgument : initCGDisplayState: cannot map display interlocks.
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorInvalidConnection : CGSGetEventPort: Invalid connection
Should work, but I just get a load of errors:
kCGErrorIllegalArgument : initCGDisplayState: cannot map display interlocks.
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorInvalidConnection : CGSGetEventPort: Invalid connection
oh, i think i ve got it! i was looking at the output from ps -aujx, and you can see, if eg TextEdit is running, the actually process is not /Applications/TextEdit.app, but rather /Applications/TextEdit.app/Contents/MacOS/TextEdit. there is some argument passed that i don t understand, but if you run that command as root from terminal, then you have it! it works, i just saved a TextEdit file in /var/private/root!
Note that i did not 'open' that file. i just ran it as a command at the prompt.
Note that i did not 'open' that file. i just ran it as a command at the prompt.
OK, so what we were previously trying to do is this:
this used to work in 10.0, but now in 10.1 if you do it, the app opens, but not as root. rather as whoever has window server and the GUI and such. it is exactly as though that user had double clicked that app.
i went fishing through the running processes, looking to see what process was associated with TextEdit.app when it was running, thinking that i would just start the process manually from the command line, instead of simulating a double-click with open. this approach works like magic! what you will discover if you look at the processes is this:
now, you see that the running process is not /Applications/TextEdit.app, but rather /Applications/TextEdit.app/Contents/MacOS/TextEdit. this makes sense, because in UNIX a program is just a file filled with executable code. it can t really be a directory, the way a .app bundle is.
there is a funny argument there associated with that (-psn_0_7340033 in this example.) just ignore it. i have no idea what that is. testuser, any idea? anyway it s not important.
so instead of open (equivalent to double click) /Applications/TextEdit, we actually launch the process that goes with it instead. then according to the rules of UNIX, the child process inherits the properties of its parent. so if we are root when we launch this program, it launches as root:
and now the file will open and you can read/write it with textedit. no more sudo vi for you!
if you try this:
it will fail. try it and see!
OK so i hope this cleared it up for you.
Code:
# open /Applications/MyApp.appthis used to work in 10.0, but now in 10.1 if you do it, the app opens, but not as root. rather as whoever has window server and the GUI and such. it is exactly as though that user had double clicked that app.
i went fishing through the running processes, looking to see what process was associated with TextEdit.app when it was running, thinking that i would just start the process manually from the command line, instead of simulating a double-click with open. this approach works like magic! what you will discover if you look at the processes is this:
Code:
#ps -aujx
USER PID %CPU %MEM VSZ RSS TT STAT TIME PPID PGID SESS JOBC COMMAND
lethe 1373 0.0 0.4 88640 3868 ?? S 0:00.71 69 69 292af70 0 /Applications/TextEdit.app/Contents/MacOS/TextEdit -psn_0_7340033now, you see that the running process is not /Applications/TextEdit.app, but rather /Applications/TextEdit.app/Contents/MacOS/TextEdit. this makes sense, because in UNIX a program is just a file filled with executable code. it can t really be a directory, the way a .app bundle is.
there is a funny argument there associated with that (-psn_0_7340033 in this example.) just ignore it. i have no idea what that is. testuser, any idea? anyway it s not important.
so instead of open (equivalent to double click) /Applications/TextEdit, we actually launch the process that goes with it instead. then according to the rules of UNIX, the child process inherits the properties of its parent. so if we are root when we launch this program, it launches as root:
Code:
# pwd
/private/var/root
# touch testfile
# chmod 600 testfile
# /Applications/TextEdit.app/Contents/MacOS/TextEdit /private/var/root/testfileand now the file will open and you can read/write it with textedit. no more sudo vi for you!
if you try this:
Code:
# open -e /private/var/root/testfileOK so i hope this cleared it up for you.
OK testuser, Ask and ye shall receive! i had to look far and wide to find out the answer to this one, and eventually i had to sleep with steve jobs, but i ve got it!!!
how-to launch carbon app from command line:
iCab is the only carbon app i have, and it is a little fishy testing out permissions with a web broswer, but i m pretty sure it worked. try it out on BBEdit for us and let us know.
cheers!
how-to launch carbon app from command line:
Code:
root# /System/Library/Frameworks/Carbon.framework/Versions/Current/Support/LaunchCFMApp /Applications/iCab &iCab is the only carbon app i have, and it is a little fishy testing out permissions with a web broswer, but i m pretty sure it worked. try it out on BBEdit for us and let us know.
cheers!
well, i ll tell you, the story is not too exciting, but here s what i did:
so carbon apps don t run like normal UNIX processes it seems. how do they get launched? running the process as it appears from ps is junk. so how does it actually work? here is my first thought. i don t know how it works, but i know someone who does: /usr/bin/open! he knows. this is a nice trick that has worked for me before (but didn t work this time):
go to apple s website, and read the source code. i thought 'open' is a command line app, so it will be in tthe source code. alas, it was not. if you think about it, it makes sense. it is a command line tool, but it is really only related to the aqua GUI, so it needn t be considered part of the underlying OS. i spent almost an hour sifting through the darwin packages though. i used this trick to understand the 'bless' command, to better understand open firmware booting. it s a small apple only command line app and you can read the source.
anyway, next i go to the developer page on apple s website. understanding the API is sure to have the answer, but only if you can understand it. i m no macos developer, so i can t wade too deeop, but sometimes you get lucky. like this time: at the developer info page for carbon APIs they have a tips & tricks page
on that page, they tell you how to use gdb to debug a carbon app. and to do it, first then load this launchCFMApp app, and then import the carbon app. and that was it. i know that loading a program into gdb is not too different from launching a program, so i give it a try. and it works. it launches that carbon bad boy. of course it works from root too, and now i m done.
now we can write our own pseudo programs. or at least some wrapper scripts. neat, i think
so carbon apps don t run like normal UNIX processes it seems. how do they get launched? running the process as it appears from ps is junk. so how does it actually work? here is my first thought. i don t know how it works, but i know someone who does: /usr/bin/open! he knows. this is a nice trick that has worked for me before (but didn t work this time):
go to apple s website, and read the source code. i thought 'open' is a command line app, so it will be in tthe source code. alas, it was not. if you think about it, it makes sense. it is a command line tool, but it is really only related to the aqua GUI, so it needn t be considered part of the underlying OS. i spent almost an hour sifting through the darwin packages though. i used this trick to understand the 'bless' command, to better understand open firmware booting. it s a small apple only command line app and you can read the source.
anyway, next i go to the developer page on apple s website. understanding the API is sure to have the answer, but only if you can understand it. i m no macos developer, so i can t wade too deeop, but sometimes you get lucky. like this time: at the developer info page for carbon APIs they have a tips & tricks page
on that page, they tell you how to use gdb to debug a carbon app. and to do it, first then load this launchCFMApp app, and then import the carbon app. and that was it. i know that loading a program into gdb is not too different from launching a program, so i give it a try. and it works. it launches that carbon bad boy. of course it works from root too, and now i m done.
now we can write our own pseudo programs. or at least some wrapper scripts. neat, i think