Re: Hurd Login Utility
This seems to be caused by a segfault, so I imagine this is not intended! Tracking down the cause... James On Tue, 29 Sep 2015, James Clarke wrote: Whilst looking through the code in utils/login.c, I noticed a security issue. Even if --paranoid is set, if you give it a UID that doesn’t exist (login treats it as a UID if the first character is a digit, with no fallback to treating it as a username), it will exit without prompting for a password (and of course prompts for a password if it is a valid UID!). Is this intentional? I was also thinking that login should prompt for a username if not provided on the command line, as with Linux and BSD. This would in fact let us get rid of /bin/loginpr (currently we go via bash just to prompt for a username, and then exec login, which seems unnecessary). Thoughts? James
[PATCH 1/1] Add missing null checks in libshouldbeinlibc
The getpwnam_r and similar functions only return non-zero on error, but not
finding the given name/UID/GID does not count as an error. When they return 0,
the value of the result (*result when looking at the arguments in the man pages)
still needs to be checked for null.
* libshouldbeinlibc/idvec-rep.c (lookup_uid): Check result for null.
(lookup_gid): Likewise.
* libshouldbeinlibc/idvec-verify.c (verify_passwd): Likewise.
(verify_id): Likewise.
---
libshouldbeinlibc/idvec-rep.c| 4 ++--
libshouldbeinlibc/idvec-verify.c | 7 ---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libshouldbeinlibc/idvec-rep.c b/libshouldbeinlibc/idvec-rep.c
index 16408a4..4fc7712 100644
--- a/libshouldbeinlibc/idvec-rep.c
+++ b/libshouldbeinlibc/idvec-rep.c
@@ -129,7 +129,7 @@ lookup_uid (uid_t uid)
{
char buf[1024];
struct passwd _pw, *pw;
- if (getpwuid_r (uid, &_pw, buf, sizeof buf, &pw) == 0)
+ if (getpwuid_r (uid, &_pw, buf, sizeof buf, &pw) == 0 && pw)
return strdup (pw->pw_name);
else
return 0;
@@ -141,7 +141,7 @@ lookup_gid (gid_t gid)
{
char buf[1024];
struct group _gr, *gr;
- if (getgrgid_r (gid, &_gr, buf, sizeof buf, &gr) == 0)
+ if (getgrgid_r (gid, &_gr, buf, sizeof buf, &gr) == 0 && gr)
return strdup (gr->gr_name);
else
return 0;
diff --git a/libshouldbeinlibc/idvec-verify.c b/libshouldbeinlibc/idvec-verify.c
index 4d9b6db..4019a04 100644
--- a/libshouldbeinlibc/idvec-verify.c
+++ b/libshouldbeinlibc/idvec-verify.c
@@ -107,7 +107,8 @@ verify_passwd (const char *password,
return pw->pw_passwd;
}
- if (getpwuid_r (wheel_uid, &_pw, lookup_buf, sizeof lookup_buf, &pw))
+ if (getpwuid_r (wheel_uid, &_pw, lookup_buf, sizeof lookup_buf, &pw)
+ || ! pw)
return errno ?: EINVAL;
sys_encrypted = check_shadow (pw);
@@ -266,7 +267,7 @@ verify_id (uid_t id, int is_group, int multiple,
{
struct group _gr, *gr;
if (getgrgid_r (id, &_gr, id_lookup_buf, sizeof id_lookup_buf, &gr)
- == 0)
+ == 0 && gr)
{
if (!gr->gr_passwd || !*gr->gr_passwd)
return (*verify_fn) ("", id, 1, gr, verify_hook);
@@ -278,7 +279,7 @@ verify_id (uid_t id, int is_group, int multiple,
{
struct passwd _pw, *pw;
if (getpwuid_r (id, &_pw, id_lookup_buf, sizeof id_lookup_buf, &pw)
- == 0)
+ == 0 && pw)
{
if (strcmp (pw->pw_passwd, SHADOW_PASSWORD_STRING) == 0)
{
--
2.5.3
[PATCH 0/1] Add missing null checks in libshouldbeinlibc
This stops /bin/login segfaulting when giving it a bad UID. However, the fact that the UID does not exist is still leaked, since libshouldbeinlibc/idvec-verify.c:verify_id falls back on asking for the root password, and indicates this by changing the prompt to "Password for root". James Clarke (1): Add missing null checks in libshouldbeinlibc libshouldbeinlibc/idvec-rep.c| 4 ++-- libshouldbeinlibc/idvec-verify.c | 7 --- 2 files changed, 6 insertions(+), 5 deletions(-) -- 2.5.3
Re: Shortest path to significant improvement in hardware support
Hi Bruno! El 29/09/15 a les 11:31, Bruno Félix Rezende Ribeiro ha escrit: My main goal working on Hurd is to get more people to use the GNU system, so we can achieve critical mass to make the system develop at an acceptably pace. In order to solve this problem it's necessary to fix the most prominent issue preventing people from migrating to it, that is, its lack of hardware support. Thus, in order to form an wider user-base as soon as possible, we need to improve Hurd's hardware support using the shortest (thus fastest) path available. For that goal's sake alone, in principle, it doesn't matter the technicalities of a particular implementation, as long as it works for the majority of use cases, it's quick to implement and easy to maintain. From that perspective I'm looking for the most straightforward way to get hardware working on Hurd --- primarily USB as it seems that it along with sound (Robert Millan's work) is what people need most. After some thought I came to the conclusion that the way to achieve these requirements is to patch core libraries like libusb to use librump directly, analogously to what Robert Millan did originally for mplayer and sound support. This way we don't have to make the settlement of wonders about "the (elegant and powerful) true Hurdish way" become a dependency of the actual hardware support the Hurd community needs so badly. What are your thoughts on that? When you say USB is one of the things people need most, are you thinking on any particular usage of USB? I.e. any device class in particular? A combination of them? I recall in earlier talk about USB we discussed about possible design options my understanding from that discussion is that there were basically three possible desirable goals: #1 multiplexing (multiple processes simultaneously using USB devices) #2 authorization (allowing unprivileged users without I/O capability) #3 compatibility with non-Rump users (e.g. CUPS or SANE) Note that if you simply patch libusb to start a Rump instance all by itself, you're giving up on goals #1 and #2. However you retain goal #3. Is this something you were already contemplating? Note that retaining goals #1 and #2 is not difficult, it just means adding a translator process to sit in-between and forward ioctls to Rump. The upside is that this is *exactly* the same thing that is missing for sound, so one could kill two birds with a single stone this way. -- Robert Millan
libusb+librump patch
Hello, GNU Hurd hackers!
Based on Robert Millan's mplayer rump patch, I was able to make a
patch to successfully build libusb-1.0 on Hurd linking it to librump.
The patch is attached. To try it, save the patch file in the current
working directory and from there follow these steps:
$ su -c 'apt-get install libbsd-dev'
$ wget
http://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.9/libusb-1.0.9.tar.bz2
$ tar xf libusb-1.0.9.tar.bz2 && cd libusb-1.0.9
$ patch -p1 < ../libusb-1.0.9+rump.patch
$ rm config.guess
$ autoreconf -i
$ ./configure --enable-debug-log && make
To test the built library, build the example application and run it.
$ cd examples && make
$ su -c './listdevs'
Now, here is the problem: When I run 'listdevs' with no USB device
connected to the box I get:
libusb: 0.00 debug [libusb_init] libusb-1.0.9
libusb: 1.87 debug [usbi_add_pollfd] add fd 4 events 1
libusb: 1.87 debug [libusb_init] created default context
libusb: 1.88 debug [libusb_get_device_list]
libusb: 1.88 debug [obsd_get_device_list]
libusb: 1.91 debug [libusb_exit]
libusb: 1.91 debug [libusb_exit] destroying default context
libusb: 1.92 debug [usbi_remove_pollfd] remove fd 4
And thus no device is listed, as expected. However, if I plug in any
USB device I get the following message after the first (libusb_init)
line:
WARNING: 1 error while detecting hardware; check system log.
It means that this message is produced by the 'rump_init' function.
The other debug messages are the same, and thus no device is listed
--- what's not right.
Do you have any idea on what's going on? Any points to facts,
procedures, concepts or documentation will be highly appreciated. If
I can't make libusb work properly when directly linked to librump, I
clearly won't be able to make a translator indirection work.
A problem at a time.
--
,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) http://oitofelix.freeshell.org/
`-'(. .)`-' irc://chat.freenode.org/oitofelix
\_/ xmpp:oitofe...@riseup.net
GNU ccd2cue maintainer
GNU Savannah hacker
GNU web translation team coordinator (Brazilian Portuguese)
GNU audio and video maintainer
DMOZ free software editor (Portuguese)
UFU FAMAT PET member
[GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily
match those of the GNU project. Hereby I express my own opinion,
style and perception, in good faith, aiming the betterment of GNU.
diff -Naur libusb-1.0.9/configure.ac libusb-1.0.9+rump/configure.ac
--- libusb-1.0.9/configure.ac 2012-04-20 03:44:27.0 -0300
+++ libusb-1.0.9+rump/configure.ac 2015-09-30 00:59:19.0 -0300
@@ -62,6 +62,12 @@
AC_MSG_RESULT([NetBSD (using OpenBSD backend)])
backend="openbsd"
;;
+*-gnu*)
+ AC_MSG_RESULT([NetBSD (using OpenBSD+rump backend)])
+ backend="openbsd"
+ LIBS="$LIBS -lbsd -lrump -lrumpuser -lrumpvfs -lrumpdev -lrumpdev_pci -lrumpdev_usb -lrumpdev_pci_usbhc -lrumpdev_ugenhc"
+CPPFLAGS="$CPPFLAGS -D__RUMP__"
+ ;;
*-mingw*)
AC_MSG_RESULT([Windows])
backend="windows"
diff -Naur libusb-1.0.9/libusb/os/openbsd_usb.c libusb-1.0.9+rump/libusb/os/openbsd_usb.c
--- libusb-1.0.9/libusb/os/openbsd_usb.c 2012-04-20 03:44:27.0 -0300
+++ libusb-1.0.9+rump/libusb/os/openbsd_usb.c 2015-09-30 00:59:16.0 -0300
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2011 Martin Pieuchot
+ * Copyright (c) 2015 Bruno Félix Rezende Ribeiro
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -26,7 +27,32 @@
#include
#include
-#include
+#ifdef __RUMP__
+ #include
+ #define RUMP_SYS_OPEN
+ #define RUMP_SYS_CLOSE
+ #define RUMP_SYS_IOCTL
+ #define RUMP_SYS_READWRITE
+
+ #undef O_RDONLY
+ #define O_RDONLY RUMP_O_RDONLY
+ #undef O_RDWR
+ #define O_RDWR RUMP_O_RDWR
+ #undef O_WRONLY
+ #define O_WRONLY RUMP_O_WRONLY
+
+ #undef ENOENT
+ #define ENOENT RUMP_ENOENT
+ #undef ENXIO
+ #define ENXIO RUMP_ENXIO
+
+ #include
+ #include
+ #include "rump_ioccom.h"
+ #include "rump_usb.h"
+#else
+ #include
+#endif
#include "libusb.h"
#include "libusbi.h"
@@ -47,6 +73,10 @@
/*
* Backend functions
*/
+
+#ifdef __RUMP__
+static int obsd_init(struct libusb_context *ctx);
+#endif
static int obsd_get_device_list(struct libusb_context *,
struct discovered_devs **);
static int obsd_open(struct libusb_device_handle *);
@@ -89,7 +119,11 @@
const struct usbi_os_backend openbsd_backend = {
"Synchronous OpenBSD backend",
- NULL,/* init() */
+#ifdef __RUMP__
+ obsd_init, /* init() */
+#else
+NULL, /* init() */
+#endif
NULL,/* exit() */
obsd_get_device_list,
obsd_open,
@@ -128,6 +162,14 @@
0,/* add_iso_packet_size */
};
+#ifdef __RUMP__
+int
+obsd_init(struct libusb_context *ctx) {
+ rump_init();
+ return 0;
+}
+#endif
+
int
obsd_get_device_list(struct libusb_context * ctx,
Re: Shortest path to significant improvement in hardware support
Hello, Robert! Em Tue, 29 Sep 2015 22:56:59 +0200 Robert Millan escreveu: > When you say USB is one of the things people need most, are you > thinking on any particular usage of USB? I.e. any device class in > particular? A combination of them? Not really --- I mean USB in general. However, if I had to choose, I'd pick USB mass storage devices. > I recall in earlier talk about USB we discussed about possible design > options my understanding from that discussion is that there were > basically three possible desirable goals: > > #1 multiplexing (multiple processes simultaneously using USB devices) > #2 authorization (allowing unprivileged users without I/O capability) > #3 compatibility with non-Rump users (e.g. CUPS or SANE) > > Note that if you simply patch libusb to start a Rump instance all by > itself, you're giving up on goals #1 and #2. However you retain goal > #3. Is this something you were already contemplating? Somewhat. I'm not quite concerned about #2, because I'm assuming the majority of people run Hurd on their personal computers. #1 is more worrying, but I think we can do without it --- at least as a proof of concept --- to get any USB working on Hurd at all. Furthermore, it might be the case that for some device classes and common uses multiplexing isn't that critical. > Note that retaining goals #1 and #2 is not difficult, it just means > adding a translator process to sit in-between and forward ioctls to > Rump. The upside is that this is *exactly* the same thing that is > missing for sound, so one could kill two birds with a single stone > this way. That's true. However, I prefer to start with the least complex approach at first, and then study its practical limitations and then develop it further, if needed. Moreover, in order to grasp every concept needed to make the ideal Hurd USB implementation, I need to reduce complexity and handle issues in isolation, learning by composition in small chunks and in a progressive manner. -- ,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) http://oitofelix.freeshell.org/ `-'(. .)`-' irc://chat.freenode.org/oitofelix \_/ xmpp:oitofe...@riseup.net GNU ccd2cue maintainer GNU Savannah hacker GNU web translation team coordinator (Brazilian Portuguese) GNU audio and video maintainer DMOZ free software editor (Portuguese) UFU FAMAT PET member [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily match those of the GNU project. Hereby I express my own opinion, style and perception, in good faith, aiming the betterment of GNU. pgpZNN5E0UMzI.pgp Description: Assinatura digital OpenPGP
