Re: Hurd Login Utility

[James Clarke]

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

[James Clarke]

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, ) == 0)
+  if (getpwuid_r (uid, &_pw, buf, sizeof buf, ) == 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, ) == 0)
+  if (getgrgid_r (gid, &_gr, buf, sizeof buf, ) == 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, ))
+  if (getpwuid_r (wheel_uid, &_pw, lookup_buf, sizeof lookup_buf, )
+ || ! 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, )
-   == 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, )
-   == 0)
+   == 0 && pw)
  {
if (strcmp (pw->pw_passwd, SHADOW_PASSWORD_STRING) == 0)
  {
-- 
2.5.3

[PATCH 0/1] Add missing null checks in libshouldbeinlibc

[James Clarke]

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

[Robert Millan]

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

[Bruno Félix Rezende Ribeiro]

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
 

Re: Shortest path to significant improvement in hardware support

[Bruno Félix Rezende Ribeiro]

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