On 2018-11-19, Daniel Colascione wrote:
> > I wonder how fast it would be holding a pid with another open()ed fd.
> > And then you need to read comm (or how you filter whom to kill).
> > It seems to me that procfs will be even slower with this safe-way.
> > But I might misunderstand the idea, excu
On Mon, Nov 19, 2018 at 8:13 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> I wonder how fast it would be holding a pid with another open()ed fd.
> And then you need to read comm (or how you filter whom to kill).
> It seems to me that procfs will be even slower with this safe-way.
> But I might
Dmitry Safonov <0x7f454...@gmail.com> writes:
>
> So, I just wanted to gently remind about procfs with netlink socket[1].
> It seems to me that whenever you receive() pid information, you
> can request some uniq 64(?) bit number and kill the process using it.
> Whenever uniqueness of 64-bit number
On Sun, 18 Nov 2018 at 18:30, Andy Lutomirski wrote:
> Here's my point: if we're really going to make a new API to manipulate
> processes by their fd, I think we should have at least a decent idea
> of how that API will get extended in the future. Right now, we have
> an extremely awkward situati
On Sun, Nov 18, 2018 at 12:17:51PM +0100, Christian Brauner wrote:
> With this patch an open() call on /proc/ will give userspace a handle
> to struct pid of the process associated with /proc/. This allows to
> maintain a stable handle on a process.
> I have been discussing various approaches exten
From: > Christian Brauner
> Sent: 18 November 2018 11:18
>
> With this patch an open() call on /proc/ will give userspace a handle
> to struct pid of the process associated with /proc/. This allows to
> maintain a stable handle on a process.
My 3c...
You need to add a version of fork() that retu
Hi Christian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc3 next-20181116]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Sun, Nov 18, 2018 at 6:47 PM Al Viro wrote:
>
> On Sun, Nov 18, 2018 at 09:42:35AM -0800, Andy Lutomirski wrote:
>
> > Now here's the kicker: if the "running program" calls execve(), it
> > goes away. The fd gets some sort of notification that this happened
>
> Type error, parser failed.
>
> D
On Sun, Nov 18, 2018 at 09:42:35AM -0800, Andy Lutomirski wrote:
> Now here's the kicker: if the "running program" calls execve(), it
> goes away. The fd gets some sort of notification that this happened
Type error, parser failed.
Define "fd", please. If it's a "file descriptor", thank you do
On Sun, Nov 18, 2018 at 12:32 PM Daniel Colascione wrote:
>
> On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wrote:
> >> That is, I'm proposing an API that looks like this:
> >>
> >> int process_kill(int procfs_dfd, int signo, const union sigval value)
> >>
> >> If, later, process_kill were to
On Sun, Nov 18, 2018 at 4:53 PM, Daniel Colascione wrote:
>> Sure, I'd propose that ptrace_may_access() is what we should use for
>> operation permission checks.
>
> The tricky part is that ptrace_may_access takes a struct task. We want
> logic that's *like* ptrace_may_access, but that works posth
On Sun, Nov 18, 2018 at 4:08 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> > The gist is to have file descriptors for processes which is obviously not
>> > a new
>> > idea. This has been done before in other OSes and it has been tried before
>> > in
>> > Linux [2], [3] (T
On Sun, Nov 18, 2018 at 4:09 PM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
>> > On 2018-11-18, Daniel Colascione wrote:
>> >> > Here's my point: if we're really going to make a new API to manipulate
>> >> > processes b
On Sun, Nov 18, 2018 at 04:31:22PM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 1:30 PM, Christian Brauner
> wrote:
> > On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
> >> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> >> > On Sun, Nov 18, 20
On Sun, Nov 18, 2018 at 1:30 PM, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
>> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
>> > On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
>> > wrote:
>> > > On Sun, Nov 18, 2018 at
On 2018-11-18, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> > On 2018-11-18, Daniel Colascione wrote:
> >> > Here's my point: if we're really going to make a new API to manipulate
> >> > processes by their fd, I think we should have at least a decent idea
>
On 2018-11-18, Daniel Colascione wrote:
> > The gist is to have file descriptors for processes which is obviously not a
> > new
> > idea. This has been done before in other OSes and it has been tried before
> > in
> > Linux [2], [3] (Thanks to Kees for pointing out these patches.). So I want
>
On Sun, Nov 18, 2018 at 10:23:36PM +0100, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> > On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
> > wrote:
> > > On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > O
On Sun, Nov 18, 2018 at 12:54:10PM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
> wrote:
> > On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
> >>
> >>
> >> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione
> >> > wrote:
> >> >
> >>
> >> >
On Sun, Nov 18, 2018 at 12:43 PM, Christian Brauner
wrote:
> On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
>> >
>>
>> >
>> > That is, I'm proposing an API that looks like this:
>> >
>> > int process_kill(int proc
On Sun, Nov 18, 2018 at 01:28:41PM -0700, Andy Lutomirski wrote:
>
>
> > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
> >
>
> >
> > That is, I'm proposing an API that looks like this:
> >
> > int process_kill(int procfs_dfd, int signo, const union sigval value)
> >
> > If, later,
On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>>
>> If, later, process_kill were to *also* accept process-capability FDs,
>> nothing would break.
>
> Except
> On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:
>
>
> That is, I'm proposing an API that looks like this:
>
> int process_kill(int procfs_dfd, int signo, const union sigval value)
>
> If, later, process_kill were to *also* accept process-capability FDs,
> nothing would break.
Exc
On Sun, Nov 18, 2018 at 12:15 PM, Christian Brauner
wrote:
>> That is, I'm proposing an API that looks like this:
>>
>> int process_kill(int procfs_dfd, int signo, const union sigval value)
>
> I've started a second tree with process_signal(int procpid_dfd, int sig)
Thanks.
> instead of an ioctl
On Sun, Nov 18, 2018 at 11:44:19AM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> > On 2018-11-18, Daniel Colascione wrote:
> >> > Here's my point: if we're really going to make a new API to manipulate
> >> > processes by their fd, I think we should have
On Sun, Nov 18, 2018 at 11:05 AM, Aleksa Sarai wrote:
> On 2018-11-18, Daniel Colascione wrote:
>> > Here's my point: if we're really going to make a new API to manipulate
>> > processes by their fd, I think we should have at least a decent idea
>> > of how that API will get extended in the futur
On Sun, Nov 18, 2018 at 10:07:31AM -0800, Daniel Colascione wrote:
> On Sun, Nov 18, 2018 at 9:41 AM, Christian Brauner
> wrote:
> > On Sun, Nov 18, 2018 at 07:38:09AM -0800, Andy Lutomirski wrote:
> >> On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione
> >> wrote:
> >> >
> >> > I had been led t
On 2018-11-18, Daniel Colascione wrote:
> > Here's my point: if we're really going to make a new API to manipulate
> > processes by their fd, I think we should have at least a decent idea
> > of how that API will get extended in the future. Right now, we have
> > an extremely awkward situation wh
On Sun, Nov 18, 2018 at 10:28 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 9:51 AM Daniel Colascione wrote:
>>
>> > I'm not entirely sure that ship has sailed. In the kernel, we already
>> > have a bit of a distinction between a pid (and tid, etc -- I'm
>> > referring to struct pid) and
On Sun, Nov 18, 2018 at 10:15 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 10:07 AM Daniel Colascione wrote:
>> Next, I want to merge my exithand proposal, or something like it. It's
>> likewise a simple change that, in a minimal way, addresses a
>> longstanding API deficiency. I'm very s
On Sun, Nov 18, 2018 at 9:51 AM Daniel Colascione wrote:
>
> > I'm not entirely sure that ship has sailed. In the kernel, we already
> > have a bit of a distinction between a pid (and tid, etc -- I'm
> > referring to struct pid) and a task. If we make a new
> > process-management API, we could p
On Sun, Nov 18, 2018 at 10:07 AM Daniel Colascione wrote:
> Next, I want to merge my exithand proposal, or something like it. It's
> likewise a simple change that, in a minimal way, addresses a
> longstanding API deficiency. I'm very strongly against the
> POLLERR-on-directory variant of the idea.
On Sun, Nov 18, 2018 at 9:41 AM, Christian Brauner wrote:
> On Sun, Nov 18, 2018 at 07:38:09AM -0800, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione wrote:
>> >
>> > I had been led to believe that the proposal would be a comprehensive
>> > process API, not an ioctl ba
On Sun, Nov 18, 2018 at 9:43 AM, Eric W. Biederman
wrote:
> Daniel Colascione writes:
>
>> On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
>>> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
> On Sun, Nov 1
On Sun, Nov 18, 2018 at 9:42 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 9:24 AM Daniel Colascione wrote:
>> Assuming we don't broaden exit status readability (which would make a
>> lot of things simpler), the exit notification mechanism must work like
>> this: if you can see a process i
On Sun, Nov 18, 2018 at 9:43 AM Eric W. Biederman wrote:
>
> Daniel Colascione writes:
>
> > On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
> >> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione
> >> wrote:
> >>>
> >>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
> >>> > O
On Sun, Nov 18, 2018 at 9:42 AM Christian Brauner wrote:
>
> On Sun, Nov 18, 2018 at 07:38:09AM -0800, Andy Lutomirski wrote:
> > On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione wrote:
> > >
> > > I had been led to believe that the proposal would be a comprehensive
> > > process API, not an ioc
Daniel Colascione writes:
> On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
>>>
>>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
>>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
>>> > wrote:
>>> >>
>>> >> O
On Sun, Nov 18, 2018 at 9:24 AM Daniel Colascione wrote:
> Assuming we don't broaden exit status readability (which would make a
> lot of things simpler), the exit notification mechanism must work like
> this: if you can see a process in /proc, you should be able to wait on
> it. If you learn that
On Sun, Nov 18, 2018 at 07:38:09AM -0800, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione wrote:
> >
> > I had been led to believe that the proposal would be a comprehensive
> > process API, not an ioctl basically equivalent to my previous patch.
> > If you had a more co
On Sun, Nov 18, 2018 at 9:09 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 8:49 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap wrote:
>> > On 11/18/18 8:17 AM, Andy Lutomirski wrote:
>> >> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
>> >> wrote:
>>
On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
>> > wrote:
>> >>
>> >> On Sun, Nov 18, 2018 at 7:38 AM, Andy
On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote:
>
> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
> >>
> >> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
> >> > I fully agree that a more comprehensive, les
On Sun, Nov 18, 2018 at 8:49 AM Daniel Colascione wrote:
>
> On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap wrote:
> > On 11/18/18 8:17 AM, Andy Lutomirski wrote:
> >> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione
> >> wrote:
> >>>
> >>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrot
On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap wrote:
> On 11/18/18 8:17 AM, Andy Lutomirski wrote:
>> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>>>
>>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
I fully agree that a more comprehensive, less expensive API for
On 11/18/18 8:17 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
>>> I fully agree that a more comprehensive, less expensive API for
>>> managing processes would be nice. But I also think that thi
On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote:
> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>>
>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
>> > I fully agree that a more comprehensive, less expensive API for
>> > managing processes would be nice. But I also
On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote:
>
> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
> > I fully agree that a more comprehensive, less expensive API for
> > managing processes would be nice. But I also think that this patch
> > (using the directory fd and ioctl) i
On Sun, Nov 18, 2018 at 3:17 AM, Christian Brauner wrote:
> +static int proc_tgid_open(struct inode *inode, struct file *file)
> +{
> + /* grab reference to struct pid */
> + file->private_data = get_pid(proc_pid(inode));
Why grab another reference to the struct pid when the inode alr
On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski wrote:
> I fully agree that a more comprehensive, less expensive API for
> managing processes would be nice. But I also think that this patch
> (using the directory fd and ioctl) is better from a security
> perspective than using a new file in /pro
On Sun, Nov 18, 2018 at 5:59 AM Daniel Colascione wrote:
>
> I had been led to believe that the proposal would be a comprehensive
> process API, not an ioctl basically equivalent to my previous patch.
> If you had a more comprehensive proposal, please just share it on LKML
> instead of limiting th
I had been led to believe that the proposal would be a comprehensive
process API, not an ioctl basically equivalent to my previous patch.
If you had a more comprehensive proposal, please just share it on LKML
instead of limiting the discussion to those able to attend these
various conferences. If t
52 matches
Mail list logo
