Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

darshie76

macrumors member
Original poster
Sep 4, 2008
56
0
Hi guys!

I am starting with Apple programming (i did many years of Visual studio programming on PC); and would love to know if is posible to call an app from another app.

This is the scenario: 3rd party app that has to be called; i can't modify it so i can simply call it form another app; and the app that call the second app, should work as "gatekeeper", checking if this application can be launched or not (if the user has username and password he will go in, otherwise it will not be able to load the second app).

All this came up because i have to limit the amount of time that other people spend on my computer, so i have to limit the games with a user and pwd (that i will change often), and limit the access also to other apps, so i can keep an eye on what is launched on my mac :)

Sounds stupid but is an issue, and there is no commercial app that let me do this....some sort of parental control thing, that's what i really need :)

It would be interesting to make this app, and since i am a beginner on xcode and objC, would love to know if someone can help me in this task.

Thanks guys!
 

toddburch

macrumors 6502a
Dec 4, 2006
748
0
Katy, Texas
If you wanted to get fancy, perhaps you could fork() a child process and set a timer in the parent. In the child, do the system() function. If your timer expired in the parent, kill the child process.
 

yeroen

macrumors 6502a
Mar 8, 2007
944
2
Cambridge, MA
here's a sketch:

remove the 'other' execute permissions from the offending executables (usually located within the .app bundle under *.app/Contents/MacOS/), change the group execute permissions to a new 'guest' group, add offending users to this 'guest' group and remove them from other groups like 'admin' or 'wheel'.

create a simple app-launcher widget with 'guest' group execute permissons that prompts for guest member's username/password, validates the password, and if successful fork/exec's the application of choice setting the effective user-id of that process to that of the executable's owner (i.e. you). after a timer has expired in the app-launcher process, send a kill signal (preferably with a warning dialog) to the child process.

you'll also need to inhibit guest users from repeatedly launching the app-launcher once their time is up (i.e. enforce a waiting period of however long you deem sufficient).

of course depending on your guest user's (kids I presume) sophistication and/or determination, they can always subvert whatever restrictions you can concoct (for example, booting into single user mode to gain root access and putting themselves in the sudoer's file)...so perhaps seeking a technical solution to a non-technical problem is the wrong way to go about this
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
as recommened above, fork() and exec() is the standard way of spawning process on UNIX systems; given any reasonably complete framework (e.g. Cocoa or Qt), there are higher-level wrappers for this functionality that demand less attention to low-level details

but my guess is if your kids are old enough and determined enough, they are going to find a way to subvert any system you can concoct (e.g. once they learn how to boot into single user mode and put themselves into the sudoer's file)...perhaps it's better to seek a non-technical solution to a non-technical problem

"Get off the damn computer or you're grounded!" always worked on me.
 

darshie76

macrumors member
Original poster
Sep 4, 2008
56
0
Thanks a lot guys !

The option to inhibit the access to the computer is not an option, same for getting their cell phone, since we are talking about adults (students) :D

I like your idea Yeroan; but i need something that will block them to block the software if they are not authorized by the first program; without giving them any chance to avoid the problem and launch directly the second app :)

Basically you can see it more like a protection of a software (like when you buy a product and you can't use it until you put username and pwd), with the difference that this one would work on apps that you can't modify
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
I like your idea Yeroan; but i need something that will block them to block the software if they are not authorized by the first program; without giving them any chance to avoid the problem and launch directly the second app :)

Basically you can see it more like a protection of a software (like when you buy a product and you can't use it until you put username and pwd), with the difference that this one would work on apps that you can't modify

Yeroen's idea wouldn't allow them to launch the app directly, because they wouldn't have permission to run it. They would only have permission to run your launcher, and it would set the euid to allow them to run the launched program(s). You would have to be sure that you hardcode what can be run, though, because if they can enter the app, they can just choose Terminal and then they can do whatever they'd like to ruin the security of the system.

You have to also choose a balance between who you're really going to block and how much effort you're going to put in. At a certain point some students (no matter what level they are at, barring, perhaps kindergarteners) are going to know more about the machine then you, and come up with a way to break your scheme. You should focus on the "bottom 90%" or so, in which having a system in place at all will be enough deterrent. You should try to stop those that will passively try to break the system, but not waste too much time trying to stop those that will actively try to penetrate the system. Obviously if you are in a position of authority, there should also be consequences for actively trying to penetrate the system so they don't have the idea that "I can, so I should".

-Lee
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.