does somebody like this?
Index: Makefile.inc
==================================================================RCS file:
/cvs/src/usr.bin/ssh/Makefile.inc,v
retrieving revision 1.21
diff -u -r1.21 Makefile.inc
--- Makefile.inc 30 Oct 2001 20:32:31 -0000 1.21
+++ Makefile.inc 16 Nov 2001 12:07:22 -0000
@@ -10,7 +10,7 @@
CDIAGFLAGS+= -Wmissing-prototypes
CDIAGFLAGS+= -Wunused
-#DEBUG=-g
+DEBUG=-g
#CFLAGS+= -DSMARTCARD
#LDADD+= -lsectok
Index: clientloop.c
==================================================================RCS file:
/cvs/src/usr.bin/ssh/clientloop.c,v
retrieving revision 1.95
diff -u -r1.95 clientloop.c
--- clientloop.c 10 Jan 2002 11:24:04 -0000 1.95
+++ clientloop.c 31 Jan 2002 17:17:19 -0000
@@ -103,6 +103,8 @@
*/
static volatile sig_atomic_t received_window_change_signal = 0;
static volatile sig_atomic_t received_signal = 0;
+/* send signal to remote program: 0 disabled, 1 enabled, 2 pending */
+static volatile sig_atomic_t send_signal = 0;
/* Flag indicating whether the user\'s terminal is in non-blocking mode. */
static int in_non_blocking_mode = 0;
@@ -173,7 +175,10 @@
signal_handler(int sig)
{
received_signal = sig;
- quit_pending = 1;
+ if (send_signal == 1)
+ send_signal = 2;
+ else
+ quit_pending = 1;
}
/*
@@ -765,6 +770,26 @@
leave_raw_mode();
}
+static char *
+sig2name(int sig)
+{
+#define SIG(x) if (sig == SIG ## x) return #x
+ SIG(ABRT);
+ SIG(ALRM);
+ SIG(FPE);
+ SIG(HUP);
+ SIG(ILL);
+ SIG(INT);
+ SIG(KILL);
+ SIG(PIPE);
+ SIG(QUIT);
+ SIG(SEGV);
+ SIG(TERM);
+ SIG(USR1);
+ SIG(USR2);
+ return "";
+}
+
/*
* Implements the interactive session with the server. This is called after
* the user has been authenticated, and a command has been started on the
@@ -778,7 +803,7 @@
fd_set *readset = NULL, *writeset = NULL;
double start_time, total_time;
int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0;
- char buf[100];
+ char *signame, buf[100];
debug("Entering interactive session.");
@@ -819,6 +844,10 @@
client_init_dispatch();
+ /* for protocol v2 we try to send the signal to the remote host */
+ if (compat20 && !have_pty && ssh2_chan_id != -1)
+ send_signal = 1;
+
/* Set signal handlers to restore non-blocking mode. */
signal(SIGINT, signal_handler);
signal(SIGQUIT, signal_handler);
@@ -899,6 +928,18 @@
xxx_kex->done = 0;
kex_send_kexinit(xxx_kex);
need_rekeying = 0;
+ }
+ if (send_signal == 2) {
+ send_signal = 0;
+ signame = sig2name(received_signal);
+ debug("Sending SIG%s to the remote host.",
+ signame);
+ packet_start(SSH2_MSG_CHANNEL_REQUEST);
+ packet_put_int(session_ident);
+ packet_put_cstring("signal");
+ packet_put_char(0);
+ packet_put_cstring(signame);
+ packet_send();
}
}
Index: session.c
==================================================================RCS file:
/cvs/src/usr.bin/ssh/session.c,v
retrieving revision 1.122
diff -u -r1.122 session.c
--- session.c 29 Jan 2002 22:46:41 -0000 1.122
+++ session.c 31 Jan 2002 17:17:21 -0000
@@ -1375,6 +1375,47 @@
}
}
+static int
+name2sig(char *name)
+{
+#define SIG(x) if (strcmp(name, #x) == 0) return SIG ## x
+ SIG(ABRT);
+ SIG(ALRM);
+ SIG(FPE);
+ SIG(HUP);
+ SIG(ILL);
+ SIG(INT);
+ SIG(KILL);
+ SIG(PIPE);
+ SIG(QUIT);
+ SIG(SEGV);
+ SIG(TERM);
+ SIG(USR1);
+ SIG(USR2);
+ return -1;
+}
+
+static int
+session_signal_req(Session *s)
+{
+ char *signame;
+ int sig;
+
+ signame = packet_get_string(NULL);
+ sig = name2sig(signame);
+ xfree(signame);
+ packet_done();
+
+ if (sig >= 0 && s->pid > 0) {
+ debug("session_signal_req: killpg(%d, %d)",
+ s->pid, sig);
+ if (killpg(s->pid, sig) < 0)
+ error("session_signal_req: killpg(%d, %d): %s",
+ s->pid, sig, strerror(errno));
+ }
+ return 0;
+}
+
void
session_input_channel_req(int id, void *arg)
{
@@ -1419,6 +1460,8 @@
}
if (strcmp(rtype, "window-change") == 0) {
success = session_window_change_req(s);
+ } else if (strcmp(rtype, "signal") == 0) {
+ success = session_signal_req(s);
}
if (reply) {
On Thu, Jan 31, 2002 at 06:18:24PM +0100, Markus Friedl wrote:> does somebody like this?I've not used it. I like the idea. I'll try it. But: When would the client receive a signal? It runs in raw mode, right? Or would this apply only to non-pty sessions? Shouldn't this be available via ~ escapes? As in ~kHUP? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
On Thu, Jan 31, 2002 at 06:18:24PM +0100, Markus Friedl wrote:> does somebody like this?It's part of the draft, that's reason enough to put it in, IMO. I like it. If anyone feels like it, the sig2name/name2sig could be made more complex to allow for arbitrary signal passing from a given system to a remote system of the same kind, which could be useful. I'm thinking of the draft text in section 4.10 of the connection protocol; Additional signal names MAY be sent in the format "sig-name at xyz", where `sig-name' and `xyz' may be anything a particular implementor wants (except the `@' sign). However, it is suggested that if a `configure' script is used, the non-standard signal names it finds be encoded as "SIG at xyz.config.guess" where `SIG' is the signal name without the "SIG" prefix, and `xyz' be the host type, as determined by `config.guess'. So much mail, so not enough time. //Peter -- irc: CareBear\ irl: Peter Stuge
On Thu, 31 Jan 2002 12:18:24 EST, Markus Friedl writes:> + if (sig >= 0 && s->pid > 0) { > + debug("session_signal_req: killpg(%d, %d)", > + s->pid, sig); > + if (killpg(s->pid, sig) < 0) > + error("session_signal_req: killpg(%d, %d): %s", > + s->pid, sig, strerror(errno));Is it safe for the server to be doing this? Isn't the server running as root when this code runs? If the process for the session exec()s a privileged program, I'm worried that this might potentially allow a signal to be sent to a program which the user would not otherwise be allowed to deliver a signal to. (I think "s->pid > 0" could be changed to "s->pid > 1", for the sake of defensiveness; s->pid should never equal 1, but if it ever did happen, the consequences might be disastrous: on some systems, process group 1 is reserved for kernel processes.) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican
On Thu, Jan 31, 2002 at 06:18:24PM +0100, Markus Friedl wrote:> does somebody like this?Should the client exit after passing the signal? Or should it wait, either for the server or for the [same?] signal to arrive again? How about a ~k escape for passing a signal without having to send it to the client? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Reasonably Related Threads
- signal messages
- getpgrp
- trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"
- "mongrel_rails stop" leaving undeleted .pid files
- trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"