Re: kill(2)

[vp@example.com (Viktor Pavlenko)]

SL Baur <steve@example.com> writes:

>[...]
>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.
>

I will look for that.

>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.

This is exactly what I'm doing. Sorry if I didn't put it clear. Though 
it's a bit longer. I wanted to avoid having this small program suid'ed.

>
>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.
>

This does sound like "plenty"! Thank you, Steve.

Viktor