Jeff,
 
Sorry about any vagueness, our understanding may not have been complete when
the documentation was written...
 
If you are in the shell, then the kill man page states:
...
     -s signal_name
          sends the signal signal_name to the process instead of the
          SIGTERM signal.
 
     -signal_name
          is an obsolete equivalent of-s signal_name.
 
     -signal_number
          is an obsolete method of specifying a positive integer which
          represents the signal to be used (instead of SIGTERM) as the sig
          argument in the effective call to kill.
...
 
As long as the UID matches, you can send the signal.  I've done this many
times from my test environment.  There is currently _no_ user on the system
able to send a signal to a process it doesn't normally have access to.  The
"privileged user" concept for signals is not implemented.
 
The kill man page lists the available signals, I have frequently used SIGSTOP/
SIGCONT to control processes "in the background" in my test environment.  The
SIGUSR1 and SIGUSR2 signals are implemented, this should have been clearly
documented; the file /usr/include/signals.h shows the names/values of all
valid signals.
 
Steve
 
Jeff Kell ([log in to unmask]) wrote:
: The documentation about posix signals is rather vague in reference to
: what "works as advertised" and what is not yet available.  Specifically,
: if you are an ordinary user, can you kill -SIGINT a process in another
: job/session executing as your own uid?  And what specific capability is
: required to kill a process under a different uid (SM? PM?).
 
: It would be nice if the operator could send non-fatal signals to a background
: process (really great if SIGUSRx signals supported too).
 
: [\] Jeff Kell <[log in to unmask]>