Re: kill(2)

[SL Baur <steve@example.com>]

Viktor Pavlenko <vp@example.com> writes in tlug@example.com:

> SL Baur <steve@example.com> writes:
>> Why do you need people to send signals?  Depending upon how fancy you

> You mean why do they want to send signals? It's better to ask them:)
> I've already asked:(

I see.  Signals are about the worst way to do IPC on Unix due to
permissions problems like you're experiencing.  I don't suppose
you're in any position to say "Unless you tell me why you need this
feature, the answer is _no_."?

> Could you also elaborate on the rest of the "plenty of non-setuid ways"?

If HP/UX implements POSIX capabilities, then you can have their
programs enabled for CAP_KILL.  Based upon the section of the manual
you originally cited, I would expect they do or something to the
equivalent.

Another way to take setuid out of the main program is to have a helper
setuid program that is setuid to take the signal, then it passes on
the signal to your main program which is not setuid.  The advantage of
this is that while you still have a setuid program, you have maybe a
10 or 20 line setuid program which you can easily perform a security
audit on.

Under the circumstances, this may be your best option.

The other methods don't involve signals.

You can use an asynchronous (SIGIO) enabled socket or FIFO.
ptys could be used the same way.

If HP/UX implements streams, you could use them in similar fashion,
except that SIGIO is named SIGPOLL.

You could use System V message queues or shared memory, however
programming them in a non-blocking manner is very tricky.  You
basically need to set up something like a pipe which can have SIGIO
enabled on it, fork and then have the child process block waiting for
input.

If you're feeling adventurous, you could write a special device
driver.  Implement one ioctl which takes the same parameters as
kill(2), but bypasses the normal security checking.