Re: [PATCH] correct_password: Handle NULL from crypt
On Sun, Feb 09, 2014 at 12:52:50PM +0100, Denys Vlasenko wrote: On Mon, Feb 3, 2014 at 5:50 PM, Lauri Kasanen cur...@operamail.com wrote: As with many other software, busybox was also broken by the glibc = 2.17 behavior change. Now crypt() returns NULL if either salt or password is invalid. What is invalid password? I just tested and crypt() returns NULL if *salt* is invalid (say, ). It's on glibc 2.17. The old behavior was to return ? (I have no old glibc at hand to check it quickly). Since we have exactly one crypt() call in the entire busybox, the easiest fix would be to just add if (NULL) return ; there. Are there downsides to that? Are you sure glibc used to return on invalid inputs? I thought it returned something unmatchable. Returning is mildly dangerous since you could end up storing a blank password in the database and allowing logins with no password, but if that's protected against, you should be fine. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] correct_password: Handle NULL from crypt
On Mon, Feb 10, 2014, at 10:35, Rich Felker wrote: On Sun, Feb 09, 2014 at 12:52:50PM +0100, Denys Vlasenko wrote: The old behavior was to return ? (I have no old glibc at hand to check it quickly). Since we have exactly one crypt() call in the entire busybox, the easiest fix would be to just add if (NULL) return ; there. Are there downsides to that? Are you sure glibc used to return on invalid inputs? I thought it returned something unmatchable. Returning is mildly dangerous since you could end up storing a blank password in the database and allowing logins with no password, but if that's protected against, you should be fine. Yes, it works that way. Tested on 2.7. - Lauri -- http://www.fastmail.fm - Send your email first class ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: mdev and post 3.6 kernels
On Mon, 2014-02-10 at 10:29 +0400, Michael Tokarev wrote: 09.02.2014 05:28, Michael J. Hammel wrote: I've been using 3.2.27 from the RPi repos with mdev and usbfs. This worked fine to load drivers for wifi and webcams. I'm trying to move to RPi's 3.10.y branch. I've found that usbfs is deprecated and now I'm not sure how to find the usb devices and load the drivers. mdev doesn't seem to report them. I have it log every event at boot time and the usb devices don't show up. Does anyone know if there are kernel config options that need to be enabled in 3.6+ (when usbfs was deprecated) for mdev to be notified of usb devices at boot time? Or maybe suggestions on what mdev should be looking at to find them? I could dig into mdev but I'm not sure where it should be looking for the devices. lsusb shows them. How about actually loading usb _controller_ drivers before trying to look up devices on usb bus? Such as ehci_pci? (this has nothing to do with usbfs btw). The RPi uses Synopsis DWC host support which is compiled into the kernel for both 3.2.27 and 3.10.25 (aka RPis 3.10.y branch). CONFIG_USB_ARCH_HAS_EHCI is not enabled in either kernel. Other USB options are also identical. I'm at work and can't get to my RPi to browse the USB device trees under /sys/bus but I'm pretty sure the devices are there. I believe lsusb shows them. I'll verify that tonight. It appears, at least on the surface, that its either some other kernel feature that needs to be enabled in 3.10.x (that wasn't available or required in 3.2.27) or mdev just isn't looking the right place for these devices. I think these devices are there when mdev is run but the notification mechanism between kernel and mdev is somehow changed in 3.10.x so mdev isn't seeing them. -- Michael J. Hammel busy...@graphics-muse.org ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
