lkml.org 
[lkml]   [2012]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectPT_EXITKILL (Was: pdeath_signal)
(add lkml/cc's)

On 11/07, Amnon Shiloh wrote:
>
> > Quoting Oleg Nesterov (oleg@redhat.com):
> > >
> > > On 11/06, Amnon Shiloh wrote:
> > > >
> > > > What I would IDEALLY like to have is a call, probably a ptrace option,
> > > > where the parent can request: "If I am ever to terminate or be killed,
> > > > then my ptraced son MUST die as well".
> > >
> > > Perhaps this makes sense...
> > >
> > > Chris, iirc you also suggested something like this? And the patch is
> > > trivial.
> > >
> > > Oleg.
> > >
> > > --- x/kernel/ptrace.c
> > > +++ x/kernel/ptrace.c
> > > @@ -393,8 +393,12 @@ static bool __ptrace_detach(struct task_
> > >
> > > __ptrace_unlink(p);
> > >
> > > - if (p->exit_state != EXIT_ZOMBIE)
> > > + if (p->exit_state != EXIT_ZOMBIE) {
> > > + if ((tracer->flags & PF_EXITING) &&
> > > + (p->ptrace & PT_KILL_IF_TRACER_EXITS))
> > > + send_sig_info(SIGKILL, SEND_SIG_FORCED, p);

No. This is wrong.

We should send SIGKILL before __ptrace_unlink() which clears ->ptrace.
Otherwise (in theory) the tracee can raise its capabilities in between.

Lets change exit_ptrace() to do this, see the patch at the end.

> That would be just wonderful, just what I need
> - it will solve me so much pain!

OK. Please see the untested/uncompiled (but trivial) patch below

- it adds PTRACE_O_EXITKILL. A better name?

- A better numeric value? Note that the new option is not equal to
the last-ptrace-option << 1. Because currently all options have
the event, and the new one starts the eventless group. 1 << 16
means we have the room for 8 more events.

- it needs the convincing changelog for akpm

> Speaking of things I need, here is another:
>
> I have a SUID-root service, which ordinary users can launch.
> This service keeps its original real-UID so that its calling user
> can send it signals, which is fine because it catches them all and
> handles them appropriately.
>
> It is not even a problem if the user kills my service using SIGKILL
> (because that closes all its external sockets), but my service is
> helpless against a SIGSTOP because it cannot be caught and stopping
> the service in an abrupt, non-orderly fashion might disrupt other users.
> (currently I solve this by having another central service watch all instances
> of my service periodically

Well, this central service can ptrace them and nack SIGSTOP... I agree
this doesn't look nice too, but:

> What I wish is that I could request (using "prctl" or whatever):
> "If a non-privileged user sends me a SIGSTOP, then let it be converted into...",

I hope we won't do this ;) But I am not going to argue if you convince
other people.

To me it would be better to simply allow to catch SIGSTOP, but I hope
we won't do this too.

Oleg.


--- x/include/uapi/linux/ptrace.h
+++ x/include/uapi/linux/ptrace.h
@@ -73,7 +73,10 @@
#define PTRACE_O_TRACEEXIT (1 << PTRACE_EVENT_EXIT)
#define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)

-#define PTRACE_O_MASK 0x000000ff
+/* eventless options */
+#define PTRACE_O_EXITKILL (1 << 16)
+
+#define PTRACE_O_MASK (0x000000ff | PTRACE_O_EXITKILL)

#include <asm/ptrace.h>

--- x/include/linux/ptrace.h
+++ x/include/linux/ptrace.h
@@ -32,6 +32,8 @@
#define PT_TRACE_EXIT PT_EVENT_FLAG(PTRACE_EVENT_EXIT)
#define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)

+#define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
+
/* single stepping state bits (used on ARM and PA-RISC) */
#define PT_SINGLESTEP_BIT 31
#define PT_SINGLESTEP (1<<PT_SINGLESTEP_BIT)
--- x/kernel/ptrace.c
+++ x/kernel/ptrace.c
@@ -457,6 +457,9 @@ void exit_ptrace(struct task_struct *tra
return;

list_for_each_entry_safe(p, n, &tracer->ptraced, ptrace_entry) {
+ if (unlikely(p->ptrace & PT_EXITKILL))
+ send_sig_info(SIGKILL, SEND_SIG_FORCED, p);
+
if (__ptrace_detach(tracer, p))
list_add(&p->ptrace_entry, &ptrace_dead);
}


\
 
 \ /
  Last update: 2012-11-07 18:01    [W:0.097 / U:3.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site