Messages in this thread | | | From | Pedro Alves <> | Subject | Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids | Date | Wed, 23 Nov 2011 16:20:44 +0000 |
| |
Hello Tejun,
On Tuesday 22 November 2011 15:33:26, Tejun Heo wrote: > Hello, > > On Tue, Nov 22, 2011 at 12:04:38PM +0000, Pedro Alves wrote: > > This whole userspace C/R stuff and being able to set the child's pid has potential > > of being very useful for GDB too, allowing a much better reimplementation of its > > old checkpointing feature [*], and allowing for a faster reverse debugging > > implementation, by being able to do faster rewinding -- restore snapshot and replay > > instructions up to N (by single stepping or running to breakpoint), rather than > > manually undoing the effects of each instruction, one by one. > > > > IOW, root only would be a shame from GDB's perspective. > > Would CAP_CHECKPOINT be a shame too?
I think CAP_CHECKPOINT (or something through some LSM) would be definitely better.
> I'm reluctant about priviledge > through fd inheritance mostly because of its unusualness. I don't > think priv management is a good problem space for small creative > solutions. We're much better off with mundane mechanisms which people > are already familiar with and is easy to account for.
fd inheritance wouldn't work for gdb; a user spawned gdb wouldn't inherit an open fd to kernel.ns_last_pid from anywhere.
-- Pedro Alves
| |