Ticket #44 (closed defect: fixed)
Opened 3 years ago
Last modified 3 years ago
libusb_open does not honor debug level under linux
| Reported by: | Ekkehard | Owned by: | |
|---|---|---|---|
| Milestone: | Component: | libusb-1.0 | |
| Keywords: | libusb_open, debug level, linux | Cc: | |
| Blocked By: | Blocks: |
Description
In spite of the debug level being set to 0, on a Linux system libusb_open causes the following message being sent to stderr:
libusb couldn't open USB device /dev/bus/usb/001/001: Permission denied. libusb requires write access to USB device nodes.
The message is factually correct, but it shouldn't be printed at that debug level.
Fix: On line 1044 in linux_usbfs.c, function op_open reads
fprintf(stderr, "libusb couldn't open USB device %s: "
"Permission denied.
"
"libusb requires write access to USB device nodes.
",
filename);
instead of an
usbi_err(HANDLE_CTX(handle),
"libusb couldn't open USB device %s: "
"Permission denied.
"
"libusb requires write access to USB device nodes.
",
filename);
With that change, libusb behaves as expected.
Change History
comment:1 Changed 3 years ago by LudovicRousseau
comment:2 Changed 3 years ago by dsd
thanks, fixed in git
comment:3 Changed 3 years ago by stuge
- Resolution set to fixed
- Status changed from new to closed
Commit 22d61cd0891d8304dfc1a70579cf154fd8e6644a fixes #44.
Note: See
TracTickets for help on using
tickets.
I reported this bug 2 years ago [1]. Maybe the problem was fixed at that time and the same error was made again some time later.
"I discover that libusb-1.0 prints some error messages in case of
error. This is a bad behavior :-)
The library could be used by a daemon with stderr closed and file
descriptor 2 used for something else. Writting to file descriptor 2
would corrupt data sent by the daemon.
So unless explicitly requested the library shall not send anything to
stdout or stderr. For example a environment variable LIBUSB_DEBUG
could be used to know if debug is requested or not. libusb-0.1.12 is
using USB_DEBUG for something similar."
This is a serious security problem. The library has no idea what stderr (fd = 2) points to. Maybe the application has closed stderr and the file handle 2 is now used to write to "/etc/passwd". Guess what will happen if/when libusb writes to stderr?
[1] http://sourceforge.net/mailarchive/forum.php?thread_name=48387AD7.50508%40gentoo.org&forum_name=libusb-devel