macOS Help: call an app from another app

Just use the system() function.

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.

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

yeroen said:

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

Click to expand...

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

I've learned a "give me your cell phone" works for just about anything.

darshie76 said:

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

Click to expand...

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