Re: Proposal: killpeer(2)

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Putting that aside for a moment, let's pretend we had a stream socket
> in this application instead of a datagram one.  I think the right
> thing to do at that point would be to add a killpeer() syscall, which
> sends a signal to the other process associated with a file
> descriptor.

With what permissions checking?

If the answer is "same as kill(2)", then you may find it crippled
unless daemons run as root, which of course is undesirable.

If the answer is "none", then suddenly processes using vanilla AF_LOCAL
sockets can get signals from peers that formerly couldn't send them
signals, thus creating DoS potential against system processes.

I'm not sure what other options exist.  Perhaps it could work only if
the other side has agreed to receive signals, with a distinctive error
if not?  (Trying to send signal 0 could probe for this.)

Another thought: what if there is other than exactly one process on the
other end?  Even for SOCK_STREAM, this is possible; multiple processes
can have file descriptors referring to a single open file table entry,
by means such as fork() or SCM_RIGHTS messages.  There may even be no
such process, if the peer socket has been closed, or if all references
to it are sitting in SCM_RIGHTS buffers in other sockets.  (Process X
has fd, sends it as SCM_RIGHTS to process Y, but X closes the fd before
Y receives the message - who is "the peer process"?  What if there are
multiple Ys who have access to the socket and could receive the
SCM_RIGHTS-bearing message?)

> This is reasonably general -- it would be useful for ptys and pipes
> as well, I think.  I think it would be a very useful tool for cleanup
> of potentially misbehaving peers in many local-IPC client/server
> applications.

I'm concerned about possible abuses of the capability.  I don't think
signals are an appropriate response to "misbehaving peers"; a more
appropriate response is generally to close the communications channel
to the misbehaving peer.

Even in the case that brought this up, I would say the right answer is
not to provide a way to kill off the process, but rather redesign the
communications mechanisms so there is no need to kill off the process.
While I don't know fuse beyond what manu@ said on Saturday, it seems to
me that the right answer is to provide something perfused can do to
ensure that it doesn't matter whether glusterfs sticks around, to break
whatever connection exists that's allowing glusterfs's persistence to
interfere with the next mount.  (Or, possibly, not something perfused
needs to do; it's armchair quarterbacking to an extent, but it seems to
me that this should be part of the unmount operation.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B