On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote: > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote: > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote: > > > From: Wade Mealing <wmealing@xxxxxxxxxx> > > > > > > Gday, > > > > > > I'm looking to create an audit trail for when devices are added or removed > > > from the system. > > > > Then please do it in userspace, as I suggested before, that way you > > catch all types of devices, not just USB ones. > > > > Also I don't think you realize that USB interfaces are what are bound to > > drivers, not USB devices, so that is going to mess with any attempted > > audit trails here. How are you going to distinguish between the 5 > > different devices that just got plugged in that all have 0000/0000 as > > vid/pid for them because they are "cheap" devices from China, yet do > > totally different things because they are different _types_ of devices? > > This sounds like vid/pid should be captured in the event. The code did that, the point is, vid/pid means nothing in the real world. So why are you going to audit anything based on it? :) > > Again, do this in userspace please, that is where it belongs. > > There is one issue that may need some clarification. The audit system has to do > everything possible to make sure that an event is captured and logged. Does > the uevent netlink protocol ever drop events because the user space queue is > full? If the uevent interface drops events, then its not audit quality in > terms of doing everything possible to prevent the loss of a record. If this > were to happen, how would user space find out when a uevent gets dropped? I may > have to panic the machine if that happens depending on the configured policy. > So, we need to know when it happens. If on the otherhand it doesn't ever drop > events, then it might be usable. I have never seen it drop events, have you? It's been pretty reliable for the past 10+ years :) thanks, greg k-h -- 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
