Quoting Alan Stern (stern@xxxxxxxxxxxxxxxxxxx): > On Fri, 23 Sep 2011, Serge E. Hallyn wrote: > > > Quoting Alan Stern (stern@xxxxxxxxxxxxxxxxxxx): > > > On Fri, 23 Sep 2011, Serge E. Hallyn wrote: > > > > > > > (re-sending to Cc: Greg and linux-usb) > > > > > > > > Add to the dev_state and alloc_async structures the user namespace > > > > corresponding to the uid and euid. Pass these to kill_pid_info_as_uid(), > > > > which can then implement a proper, user-namespace-aware uid check. > > > > > > > > Changelog: > > > > Sep 20: Per Oleg's suggestion: Instead of caching and passing user namespace, > > > > uid, and euid each separately, pass a struct cred. > > > > > > This should be broken up into two separate patches: One to add > > > kill_pid_info_as_cred() and the other to modify the usbfs driver. > > > > It seems like that would make the first patch harder to review (since > > it won't just show the changes from kill_pid_info_as_uid to > > kill_pid_info_as_cred), but I'll go ahead and split it up. I assume > > kill_pid_info_as_uid should be removed in a third patch? > > No, what I meant was that all the changes to /kernel/signal.c should be > in one patch and all the changes to drivers/usb/core/devio.c should be > in a second patch. But doing that in two patches would not be bisect-safe. > You did check to make sure there are no other references to > kill_pid_info_as_uid() in the kernel? Yup. > > > > if (signr) > > > > - kill_pid_info_as_uid(sinfo.si_signo, &sinfo, pid, uid, > > > > - euid, secid); > > > > + kill_pid_info_as_cred(sinfo.si_signo, &sinfo, pid, cred, secid); > > > > > > This continues a bug that already exists in the current code. Once > > > ps->lock is released, there is no guarantee that the async structure > > > will still exist. It may already have been freed, and the reference to > > > > Yikes. That makes sense. I'll fix that for the cred and the pid as well > > then? > > Right. Ok. thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
