bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bind() broken for AF_UNIX in chroots


From: Michael Banck
Subject: bind() broken for AF_UNIX in chroots
Date: Fri, 29 Jun 2007 03:00:54 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hi,

(The "use-case" here being that for some funky reason dbus needs to get
started in order to build core parts of Gnome in Debian, thus Gnome
is broken in Debian GNU/Hurd until this is fixed, or we decide to build
Gnome completely manually from now on)

The following program works fine in a real installation, but fails with
EADDRNOTAVAIL if run in a chroot:

#include <sys/socket.h>
#include <sys/un.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>

#define SOCKET_ADDR "/tmp/foo"

int main(int argc, char** argv)
{
        int fd;
        struct sockaddr_un addr;
        size_t path_len;

        addr.sun_family = AF_UNIX;
        path_len = strlen(SOCKET_ADDR);
        strncpy(addr.sun_path, SOCKET_ADDR, path_len+1);

        fd = socket(PF_UNIX, SOCK_STREAM, 0);
        if (bind(fd, (struct sockaddr*) &addr, SUN_LEN(&addr)) < 0)
                printf("Error: %s\n", strerror(errno));
}

(This code is a minimal reduction of the dbus-daemon startup code, which
fails in the same way)

The problem is apparently that /hurd/ifsock is set as a passive
translator in [glibc]/sysdeps/mach/hurd/bind.c via
__file_set_translator() and is not aware that it is started in a chroot:

<marcus> azeem: it seems that ifsock talks to a different pflocal than
        the application
<marcus> azeem: could it be that it escapes the chroot somehow?
<azeem> what is "it"? ifsocks? the application?
<marcus> yes
<marcus> ifsocks
<marcus> one or the other ;)
<youpi> the starting of the translator ?  (that possibly doesn't even
        know that there is chroot at stake)
<marcus> ah, hm
<marcus> youpi: yeah
<youpi> how should it know that anyway ?
<marcus> well
<marcus> youpi: oh
<marcus> you mean libc sets a passive translator?
<marcus> right

Otherwise, maybe this is a problem with the chroot setup, marcus
suggested setting a firmlink to the main pflocal as a work around, but I
was not successful in doing that (ordinary pipes work in the chroot,
by the way)

Is this an error in glibc or by myself?  Can anybody suggest a
work-around maybe, so that Gnome can be built again?


Michael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]