On 15/08/07, Paul Moore wrote: > On Friday, August 07, 2015 02:37:15 AM Richard Guy Briggs wrote: > > On 15/08/06, Paul Moore wrote: > > > > > I guess what I'm saying is that I'm not currently convinced that > > > there is enough value in this to offset the risk I feel the loop > > > presents. I understand the use cases that you are mentioning, the > > > are the same as the last time we discussed this, but I'm going to > > > need something better than that. > > > > Can you better describe the loop that concerns you? I don't quite see > > it. > > It would be the only loop in the patch, look at the for loop in > audit_filter_rules() which iterates up the process' parent chain.
Sorry, I should reword that... What risk do you see in that loop? It works up the task ancestry tree until it triggers, or hits init for that PID namespace that terminates the loop. Do you see a risk in the numerical pids rolling underneath the loop? I *do* notice that find_task_by_vpid(pid_t) must be replaced with find_task_by_pid_ns(pid_t, &init_pid_ns), since task_struct->pid is always stored in the initial PID namespace. > paul moore - RGB -- Richard Guy Briggs <rbri...@redhat.com> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
