macOS Way to prevent SIGKILL

[J::2]

I want to make a Client-Server Application in which once a client Application is connected to Server, user at client side should not be able to terminate it unless permission is given by server.
Client side User should not be able to terminate Client Application by kill -9 <pid> or Force Quit from Activity monitor

I have trapped all other signals but not able to find a way to prevent SIGKILL to my Application ?

Any help would be really great Thanks

 

[lee1210]

You are going to have a very hard time telling someone they can't kill something on their own machine. The best bet would be to have it run under init (or launchd, i think that's the more Appley way to do things) as root on startup. That way regular users can't just kill it (unless they sudo kill it, but again, if the user has root on the machine, you're not going to stop them from killing anything).

-Lee

 

[J::2]

Hi Lee

Thanks for Reply

I cant launch that Client at startUp , it should be started just like any other application by double click

 

[notjustjay]

It is not possible to ignore a SIGKILL (unless you are the init process). That is part of the definition of SIGKILL:

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

If there is something you need to prevent the user from being able to interrupt, I suggest you need to rethink how your program is designed and come up with some fail-safe algorithms, including the possibility of a separate monitor process that monitors the health of the "unkillable" process and creates a new one to replace it and resume its operation if killed.

And remember that any "uninterruptable" process can still be shut down by powering off the box...

Otherwise, you're looking at modifying the kernel.

 

[Cromulent]

One of the definitions of malware is that it hijacks a computer and stops a user from quitting it. I'm not suggesting that is what you are trying to do, but users will equate a program that does that to malware whether it is or is not actually malware.

 

[autorelease]

You can't. Period.

There are certain conditions in which a process might not terminate when sent SIGKILL; for example, if it's a zombie or if it's blocked waiting for a neverending I/O operation. However, a process can't do anything in these states, so it's not possible to have a process performing computation and not responding to signal 9.

Rethink your architecture.

 

[iSee]

What are you trying to accomplish?
Perhaps we can help you adjust the design of your app so you don't need to block SIGKILL.

 

[J::2]

I want to create an Application that is once connected to some Remote Application using TCP Port then Users at Local Machine should not be able to terminate it in any way(includes SIGKILL and Force Quit...) unless it is allowed from Remote Machine.

 

[notjustjay]

You haven't explained WHY you require this behaviour. Will something bad happen if the client quits before the server is ready to let it go? Remember that the internet connection could drop, there could be a power outage, the user could trip on the cord and unplug the computer, the computer could crash, there are still any number of scenarios in which the connection between the client and server could be disconnected even if you were able to ignore a Force Quit or SIGKILL.

Since there's no way you can prevent it from happening, the next best thing is to make sure your architecture is such that there will be no damage, data loss, or ill effects from this occurring.

What does your client/server application do, anyway?

 

[J::2]

Remember that the internet connection could drop, there could be a power outage, the user could trip on the cord and unplug the computer, the computer could crash, there are still any number of scenarios in which the connection between the client and server could be disconnected even if you were able to ignore a Force Quit or SIGKILL.

Yes that is considered,it is fine if any of the above mentioned scenarios takes place.Client side user can kill Application in these cases.

But if everything works fine and client is connected to server, then Client side user should not be able to terminate Application by any way

 

[gnasher729]

I want to create an Application that is once connected to some Remote Application using TCP Port then Users at Local Machine should not be able to terminate it in any way(includes SIGKILL and Force Quit...) unless it is allowed from Remote Machine.

That is ridiculous. If it is a desktop machine, I unplug the power cable. If it is a laptop, I take it 50 meters away from my wireless router. So what is your server going to do about that?

As soon as a customer figures out they can't quit an application, you have one very, very angry ex-customer. Talk to a lawyer whether preventing a user from controlling their own computer in this way might be considered a crime, it might quite well fit several anti-hacking laws.

And you keep answering the wrong question. Why do you want to do this nonsense?

 

[J::2]

It is allowed to kill that Application using sudo Kill command but should not be killed by kill -9

I am assuming user should not be knowing the root password.

Is there any way to do so?

 

[Cromulent]

It is allowed to kill that Application using sudo Kill command but should not be killed by kill -9

I am assuming user should not be knowing the root password.

Is there any way to do so?

Yes, have the application run as root (probably as a daemon started by launchd).

 

[J::2]

But the application is not required to launch at StartUp but as usual application by double click

So in this case, I can have my application to be launched by double click as root

Is there any way to do so? It should not require Root Password when launched

 

[janil]

Is there any way to do so? It should not require Root Password when launched

That's a security violation.. the same thing viruses and other malware apps want to do. If you could do what you wish, without a password, then any random application could do the same.

Why do you want to introduce dangerous behavior that would open up OS X to exploits?

 

[notjustjay]

Well folks, I'm done here. The poster signed up an account on MacRumors just to ask these questions, has no previous posting history, and is being evasive about why they want to write an unstoppable app which could potentially be a virus or other malware.

Until we get more details on what exactly is going on, I'm not offering any more help.

 

[Cromulent]

Well folks, I'm done here. The poster signed up an account on MacRumors just to ask these questions, has no previous posting history, and is being evasive about why they want to write an unstoppable app which could potentially be a virus or other malware.

Until we get more details on what exactly is going on, I'm not offering any more help.

I think you are most likely right. It sounds a lot like he is trying to write a Trojan or other such application.

 

[lee1210]

Is there any way to do so? It should not require Root Password when launched

Authorization services require the user's password, not the root password. Is this acceptable? If so, even though i think it's a very bad idea, you could have a wrapper run, use Authorization Services to escalate permissions, then run another process as root which would be safe from the user killing it. Again, i don't think this is a good approach, but would be possible.

As others have said, i think this design doesn't make sense, and you have not explained at all why you need this behavior. If a user starts an application they damn well better be able to stop it. If it is a system service, this is not the case, which is why i suggested it originally.

There may be ways to achieve what you want with setuid, but understand that this is designed to empower a user to run something with higher permissions, not keep them from stopping it.

The real moral here is what you want to do, even if possible, is the wrong decision. There have been many requests for you to explain what specifically you're needing to do, and why you think preventing the user from killing the program is the right way to achieve it. If you do, we may be able to help more.

-Lee

 

[J::2]

It is a Process inspector Application in which a Server wants to log processes running on client machines. Once client is connected to Server, Client Application should not be closed by user at client side to that it can hide its processes from logging at Server.

I think now it will become clear.

Sorry for all trouble.

Please help.

 

[lazydog]

Well you could get the server to ssh into your client and run it's process monitor program itself. You would need to create a user account for the server on the client and set up ssh keys etc.

b e n

 

[Cromulent]

It is a Process inspector Application in which a Server wants to log processes running on client machines. Once client is connected to Server, Client Application should not be closed by user at client side to that it can hide its processes from logging at Server.

I think now it will become clear.

Sorry for all trouble.

Please help.

That sounds almost exactly the kind of thing a daemon is best suited too if you ask me.

Just have it send out reports say once an hour or something or less.

 

[savar]

But the application is not required to launch at StartUp but as usual application by double click

So in this case, I can have my application to be launched by double click as root

Is there any way to do so? It should not require Root Password when launched

Whatever you're trying to do, you're not going to be able to do it.

1) You're trying to do something either illegal, or at the very least extremely annoying to your "users".
2) You clearly do not possess a good technical understanding of application programming anyway.

And yet, like a car wreck, here I am... rubbernecking through the rest of the thread.

 

[lee1210]

If this is legitimate, there are a lot of other ways to handle this. If you don't trust your users not to kill something, why trust them to run it in the first place?

The suggestion of running the command with ssh -c from a remote system and reaping the results on some interval seems like a pretty good one. You could also schedule a task in the root processes cron to do the monitoring, etc. If you need to absolutely know in real time when a process goes down, you'd have to run this as a root-owned background process that starts with the system. What will monitor this process, though? Are you sure you will write something bullet-proof that can run for years without dying?

-Lee

 

[antibact1]

Probably some crazy parent trying to monitor what their teen with a little bit of computer knowhow is doing.

 

[GorillaPaws]

Probably some crazy parent trying to monitor what their teen with a little bit of computer knowhow is doing.

Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?