On 25 April 2014 23:01, Oleg Nesterov <o...@redhat.com> wrote: > On 04/25, Eric W. Biederman wrote: >> >> Oleg Nesterov <o...@redhat.com> writes: >> >> > Well. I _think_ that __fput() and ima_file_free() in particular should not >> > depend on current and/or current->nsproxy. If nothing else, fput() can be >> > called by the unrelated task which looks into /proc/pid/. >> > >> > But again, task_work_add() has more and more users, and it seems that even >> > __fput() paths can do "everything", so perhaps it would be safer to allow >> > to use ->nsproxy in task_work_run. >> >> Like I said, give me a clear motivating case. > > I agree, we need a reason. Currently I do not see one. > >> Right now not allowing >> nsproxy is turning up bugs in __fput. Which seems like a good thing. > > This is what I certainly agree with ;) >
Hi, IMA uses kernel_read API which does not know anything about caller. And of course security frameworks are at guard as usual. Exactly after reading first Eric's respons, I thought why to scratch the head when task work queues are indeed designed for tasks... And if you to dig for the history, IMA-appraisal was stuck due to lockdep reporting even though it was on non-everlaping cases. IIRC files vs. directories... After that IIRC Al Viro discussed about delayed fput and IIRC Oleg (sorry if I am wrong) introduced task work queues. So IMA-appraisal was able to be upstreamed... That was ~3.4 time frame, IIRC Name space also dated around ~3.4?? Apparmor namespace change was also around that time. 3.10 introduces this name space order change and broke IMA-appraisal. Isn't it a clear motivating case??? - Dmitry > Oleg. > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, Dmitry -- 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/