Re: gdb and attaching processes

[Roland McGrath]

Hmm.  I am not in a position to actually debug this, but I am reading the
gdb sources and I think I understand what is happening.  In gdb/inflow.c is
the following comment and code, which gets run when you do an "attach"
(among other times).

        /* If attach_flag is set, we don't know whether we are sharing a
           terminal with the inferior or not.  (attaching a process
           without a terminal is one case where we do not; attaching a
           process which we ran from the same shell as GDB via `&' is
           one case where we do, I think (but perhaps this is not
           `sharing' in the sense that we need to save and restore tty
           state)).  I don't know if there is any way to tell whether we
           are sharing a terminal.  So what we do is to go through all
           the saving and restoring of the tty state, but ignore errors
           setting the process group, which will happen if we are not
           sharing a terminal).  */

        result = tcsetpgrp (0, inferior_process_group);

As the comment says, this might not be something that should be done.  In
your case of attaching to a process that's on another terminal, changing
the pgrp should not be done.  This code relies on tcsetpgrp to refuse to
change the pgrp (and return EPERM instead) when the inferior process is not
in the same session as gdb.  POSIX.1 requires this error be reported in
that case, but the Hurd doesn't do it.

You've actually stumbled onto a pretty subtle oversight that only came to
light because of this odd usage.  But gdb's usage is perfectly correct and
reasonable according to the standard.  

The code in term that implements tcsetpgrp (which is just the TIOCSPGRP
ioctl, aka the tioctl_tiocspgrp RPC) doesn't check the pgrp value at all.
So what happens is this tcsetpgrp call succeeds in changing the pgrp of the
terminal, so C-c et al send signals to the wrong process (which won't
accept them, because they don't use its proper ctty port).

I'm not sure what the best way to fix this is; it might not be pretty.  The
required check is that the calling process be in the same session as the
pgrp it specifies.  One way to establish this is something like requiring
that the caller present the session ID port, but that leaks a capability
that term doesn't ordinarily have.  term can also just do getsid on the pid
given in term_ctty_open for that protid, but there is no kind of constraint
on what pid the client passes there, so it is not a secure check.