Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Jun 2001 22:42:17 +0200
From:      Gerhard Sittig <Gerhard.Sittig@gmx.net>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: /usr/bin/host doesn't work in jail ...?
Message-ID:  <20010604224217.A253@speedy.gsinet>
In-Reply-To: <200106041659.SAA23372@lurza.secnetix.de>; from olli@secnetix.de on Mon, Jun 04, 2001 at 06:59:17PM %2B0200
References:  <200106041659.SAA23372@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 04, 2001 at 18:59 +0200, Oliver Fromme wrote:
> 
> [ host(1) itself works, but hot inside jails ]
> 
> I'm at a loss right now.  nslookup doesn't work either when
> used within a jail, but works fine outside.  The IP number is
> OK.  Everything seems to be OK.  It's a FreeBSD 4.3.

Is this 4.3-RELEASE?

Back in last October it was working (I used the host(1) command
in PR ports/22316 to determine if we're jailed).  Checking once
more (FreeBSD 4.3-STABLE, sources cvsupped 2001-05-31 03:00 CEST
from cvsup.de.freebsd.org) everything is still fine:

shell$ ps ww$$
  PID  TT  STAT      TIME COMMAND
12007  p1  SsJ    0:00.13 /usr/local/bin/bash
shell$ host ns.gsinet.sittig.org
ns.gsinet.sittig.org has address 192.168.11.150
shell$ uname -a
FreeBSD shell.gsinet.sittig.org 4.3-STABLE FreeBSD 4.3-STABLE #1: Sun Jun  3 12:01:49 CEST 2001     root@dura.gsinet.sittig.org:/usr/obj/usr/src/sys/DURA  i386

Since nslookup(1) doesn't work either I assume the problem spot
is somewhere else.  Things I would check:
- do you have a NIC in this machine?
- do you use an ifconfig alias for the jail?
- does *any* UDP communication work from inside the jail (to
  itself and outside)?  Can you play with /usr/ports/net/netcat?
  jail$ echo OHYES | nc -l   -u  -p 8080
  jail$ echo HELLO | nc -w 1 -u $IP 8080
  host$ echo HELLO | nc -w 1 -u $IP 8080
- do you have a packet filter in the way?  (but this would result
  in "operation timed out" or "connection refused" and doesn't
  seem to apply here)

> I ktraced /usr/bin/host both outside and inside the jail.
> The difference occurs when it tries to connect to a socket
> (after reading /etc/resolv.conf).  This is the UDP socket
> to the nameserver, I guess.
> 
>    [...]
>    84730 host     CALL  socket(0x2,0x2,0)
>    84730 host     RET   socket 3
>    84730 host     CALL  connect(0x3,0x12087231c,0x10)
>    84730 host     RET   connect -1 errno 22 Invalid argument
> 
> When outside of the jail, the connect() succeeds (RET 0).
> I even considered rebooting the box, just to see if that
> helps.  Yes, I'm desperate.  :-)

Can you dump the calling parameters?  Does ktrace(1) provide this
information?  The second parameter to connect(2) is the address
to connect to, the third the size of this address description.  I
can only see a reason for the failure in the address structure
since the socket handle is valid (returned from socket(2) just a
few microseconds before) and the length is reasonable for IPv4.

BTW:  Wasn't there a bug in the gnats database about processes
failing (forgetting) to bind(2) their sockets to an address?
Search the PRs for "jail" to see if it's been fixed since.

Oh, and check you sysctl's -- especially those to influence
jail's behaviour:

dura# sysctl -a | grep jail
jail.set_hostname_allowed: 0
jail.socket_unixiproute_only: 1
jail.sysvipc_allowed: 0

Although when things work with this restrictive setup, they
should always work.  Hmmm ...

You did configure your jail's /etc area, didn't you?  Is your
jail's /etc/resolv.conf the same as the surrounding host's one?


> Oh by the way:  When I enter the jail, the configuration of
> the lo0 interface gets deleted (and I can't bring it back
> within the jail):

That's one of the design goals of a jail:  to provide resources
for manipulation only when they are available for the jailed
process group exclusively -- i.e. when it's shared it's harder to
change so you cannot mess your neighbours easily. :)  That's why
I ask above for the NIC and an alias you assigned to the jail.
Check your `ifconfig` output (with _no_ parameters to see *all*
the jail's interfaces).

And yes, this very IP number you pass to the jail(8) command is
further given to the jail(2) call and is the _only_ address you
can use in this process group to send from as well as to set up
daemons on.  That's about the only drawback of jail(2)'s current
status when you think of virtual server farms.  But the problem
is not simple to solve, Robert Watson sent an article discussing
this topic lately.  You have to stick with one IP and use
hostname based virtual server distinction mechanisms.

Date: Tue, 8 May 2001 23:54:04 -0400 (EDT)
From: Robert Watson <rwatson@freebsd.org>
To: Dave Whitaker <freebsd-security@pozer.org>
Cc: freebsd-security@freebsd.org
Subject: Re: Jails and FreeBSD4.3
Message-ID: <Pine.NEB.3.96L.1010508233716.11741q-100000@fledge.watson.org>


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010604224217.A253>