Sending signals to process running as another user

[Olivier Masse]

My users have a proprietary application that sends signals to other processes. It works fine when all processes run as the same user, but I would like to know if there's a way to signal a process when it is running as another user.

Let's assume that joe is running process1 and bob is running process2. If process1 needs to send a signal to process2, it will not work since they are not the same user.

I can't wrap the binaries under sudo or rbac because in reality it is more complex than this example, with many processes being forked directly from a spawner.

The only thing that I'm thinking of is changing the ownership of the process1 and process2 binaries to a dummy user, and putting a setuid on it. In theory, everytime they are started their effective uid should be dummy and they'll be able to signal each other.

Are there any other possibilities?

Points will be awarded, TIA.

[Steven E. Protter]

Shalom,

Dangerous on the security front, but could work and make you fail a SOX or security audit.

Give the script that does this suid root powers.

Only root can kill processes other than itself.

Any solution to this requires root priviledges.

Or decide not to do it.

SEP

[Steven E. Protter]

Shalom,

Dangerous on the security front, but could work and make you fail a SOX or security audit.

Give the script that does this suid root powers.

Only root can kill processes other than own.

Any solution to this requires root priviledges.

Or decide not to do it.

SEP

[A. Clay Stephenson]

This is a case where reading the man 2 kill page will really tell you how feasible your plan is --- but to cut to the chase, the answer is no. A kill() can only send signals to processes whose effective UID's match unless the sender's UID is 0. If signals were handled any other way, absolute chaos would result because any user would be able to kill() any other user's process.

Your setuid wrapper idea will provide a solution.

[A. Clay Stephenson]

From a security standpoint, having your wrapper run with an effective UID of a non-root user is OK. I would also have the wrapper log the real UID along with a timestamp before the exec() is done.

[TwoProc · Accepted solution]

You've covered the two easiest methods (sudo and setuid) that I can think of, and you're telling us that sudo is just not feasible, so that just leaves setuid. Which, is a method I've used and I like. The only trick is to make double-danged sure that the rights to write to the executable are watched and maintained carefully.

A few possible thoughts:

The are "group" permissions for execute on the binary, can signals be sent from the same group? If you already know the answer to this one (I don't) you could try that.

A few more possible methods:

A) have a file out there somewhere with a group policy on it wherein a command could be written to it by a group member. You have a process that wakes up every so often and looks at the file contents and if there is a "command" to signal a process, it does so, and then removes the "command" from the file, or marks it as completed (better).

I've done the above for a few processes in the past and this works well if you don't need an immediate response, and it's OK if it takes 3 minutes or so to act on the "command" signal put in the file. The gotcha is careful maintenance of permissions on the "command" file.

B) If this application is hooked to a database, then create a table, and give the users access to it that need it. They can write a record in the file to ask for a signal to be sent to a process. Your program once it sees the "command" can act on it. This is basically the same as the A) option, but just from a database standpoint.

If the above named database is an Oracle database, I'd create a pipe and have a custom program read the pipe for work to be done. This eliminates the whole issue of timing and looping (and therefore waiting). As soon as a request is made to the pipe (via procedure created with AUTHID privelages to the pipe itself), you'd act on it with your pipe processing code.

There is also the possibility of job queueing for Oracle (which is newer) to do the same idea as above (but I'm just getting old apparently).

Keep in mind that the idea of pipes and queues for managing this are probably available in some form for whichever database you may be using already.

If you don't have a database available with pipes or queues, you usually do this with a database sequencer (counter). Create a custom sequencer with a counter which increments by one every time it is read. If a group user needs to signal your program (that the dummy owns) he would just select from the sequencer, your own program could just look at the sequencers.nextval and if it is odd, then send a signal, then read from the sequencer , which would reset the sequencer back to even. Careful control over who can read from the sequencer would be the key to that system.

HTH with some ideas.

[Olivier Masse]

Thanks for all your answers. I've looked into the more modern kernel stuff (compartments, fine-grained privileges) and I still don't see any way signals can be controlled in this fashion.

Guess I'll have to go with a setuid bit, which is ok with me as long as it's not owned by root.

[A. Clay Stephenson]

Well, rather than using files or database tables there is already a mechanism built-in for interprocess communication. Let's see, it's called "InterProcess-Communication" (IPC). Probably the best fit for you would be IPC messages and these allow processes to pass messages between one another; however, unlike with signals, there is no immediate response (unless the receiver is polling rather often) so the IPC approach (as well as the file method) does suffer from latency unless you poll often -- which could make it a resource hog.

There is also the approach of setting up sockets and using select(). This approach would have the added benefit of working over multiple boxes.

[Steven E. Protter]

Shalom again,

I think the shared memory approach is better, or IPC if the application is still not written yet.

It gives you the advnatages and disadvantages of using a commonly used technology for communicating within users.

The upside is commonality.

The downside is resource competition with oracle, SAG, apache and many other vendor applications.

SEP

[Olivier Masse]

I'll suggest to the developpers that they use IPC instead of signals (they use IPC a lot elsewhere; don't know why they used signals when they ported the app to HP-UX).

Thanks for all the replies.

[Olivier Masse]

.

[TwoProc]

For a database admin and former programmer:

"When you have a hammer, everything looks like a nail".