Hello Alan, Here is the sample device ID from HP Deskjet 2000 J210 series printer. MFG:HP;MDL:Deskjet 2000 J210 series;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CH390A;CID:HPIJVIPAV1;LEDMDIS:USB#07#01#02,USB#FF#04#01;SN:CN03N1C06M05HY;S:038000C484001021002c1f0001ec2880032;J: ;Z:0102,05037460009600,0600,0c0,0e00000000,0f00000000,10000008000008,12000,143,150,16361a3746000316da15ae0003,17000000000000;: get_device_id does not contain any information related to the user who initiates the print job, indeed it contains only the device information (static + dynamic). Static Information includes: -Printer model Name -Printer Language supported -Manufacturer -Serial Number -Some more static information Dynamic information: - Printer Status (Idle, Paper Jam, Out of paper etc.) - Ink Levels, types, regions etc. - Installable options (Duplexer Unit, trays etc.) - Some more dynamic data.... Thanks, Sanjay -----Original Message----- From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] Sent: Friday, July 12, 2013 11:55 PM To: Hans de Goede Cc: USB list; Kumar, Sanjay Subject: Re: [PATCH] usbfs: Allow printer class 'get_device_id' without needing to claim the intf On Fri, 12 Jul 2013, Hans de Goede wrote: > > Are there any security implications to allowing any user on the > > system to send a get_device_id request to a printer while it is in > > the middle of a print job? > > To the best of my (limited) knowledge, no. As you indicated in the > thread about this on the libusb list, some devices are known to have > firmware bugs, which cause them to drop bulk-transfers when a ctrl > transfer issued while a bulk transfer is in progress. So there could > be a DOS issue, but such a device can easily be DOS-ed with > control-requests which don't require a specific interface to be claimed, such as requests to get descriptors. > > Also note that even after this patch, only users with rw access to the > relevant /dev/bus/usb/xxx/yyy node can issue a get_device_id request, > and if they have such access they can also detach any other driver and > claim the interface, so of they are malicious they can already issue > such a request. The problem is that for non malicious users detaching > the driver of another user is not really desirable / the right thing to do. I had in mind something more like one user reading the contents of another user's print job. Does get_device_id expose a significant amount of information of that sort? Alan Stern -- 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
