Bug 117711

Comment 1 Mark Linimon 2007-10-31 09:42:33 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).

Comment 2 Remko Lodder 2007-10-31 09:55:13 UTC

Isn't this just behaviour of RPCbind which selects some random sockets
by default? the -h is used to bind it to a specific IP address, not to
bind it to specific ports (as far as i can recall), so what you are
printing is really what I would expect it to be.

Matteo, you worked on this recently, can you shed a light on this? and
if my reasoning above is correct, can you please close the ticket since
it's desired behaviour?

Thanks
remko

-- 
Kind regards,

     Remko Lodder               ** remko@elvandar.org
     FreeBSD                    ** remko@FreeBSD.org

     /* Quis custodiet ipsos custodes */

Comment 3 Matteo Riondato 2007-10-31 15:12:02 UTC

On Wed, Oct 31, 2007 at 10:55:13AM +0100, Remko Lodder wrote:
> Matteo, you worked on this recently, can you shed a light on this? and
> if my reasoning above is correct, can you please close the ticket since
> it's desired behaviour?

I know there are problems with the implementation of "-h" in rpcbind,
and I'm working on them. I'll assign this PR to me and look at it with
more attention.
Thanks and Best Regards
-- 
Matteo Riondato
FreeBSD Volunteer (http://www.FreeBSD.org/)
FreeSBIE Developer (http://www.FreeSBIE.org/)
GUFI Staff Member (http://www.GUFI.org/)

Comment 4 Matteo Riondato 2007-10-31 15:12:25 UTC

Responsible Changed
From-To: freebsd-net->matteo

I'll take care of this PR

Just so that it is clear on the PR, the desired behaviour would be to
have those random ports bind to the interface specified by -h. The
problem is not that random ports are being opened, but that they are
being opened on all interfaces.

From my sockstat output:
(first run)
root     rpcbind    2696  8  udp6   *:617                 *:*
root     rpcbind    2696  13 udp4   *:944                 *:*
(second run)
root     rpcbind    2701  8  udp6   *:943                 *:*
root     rpcbind    2701  13 udp4   *:804                 *:*

Those should be binding to 192.168.0.3:<port> instead of *:<port>

Thanks for you work on this, Matteo, let me know if you want me to try
anything or any other help I can provide.

Regards,
Carlos.

Comment 6 Matteo Riondato 2008-02-03 14:12:48 UTC

State Changed
From-To: open->feedback

Can you please try the patch (against -CURRENT) at  
http://people.freebsd.org/~matteo/diff/117711rpcbind.diff 
Thanks

Comment 7 Mark Linimon 2010-06-19 05:45:42 UTC

Responsible Changed
From-To: matteo->freebsd-bugs

Reset PR assigned to inactive committer. 

To submitter: is this problem report still relevant to recent versions of 
FreeBSD? 

Hat:	gnats-admin

% sockstat -4l | grep rpcbind

% grep rpcbind /etc/rc.conf.local
rpcbind_flags="-h 192.168.119.6"
rpcbind_enable="YES"

% sudo /etc/rc.d/rpcbind start
Starting rpcbind.

% sockstat -4l | grep rpcbind
root     rpcbind    4265  9  udp4   127.0.0.1:111         *:*
root     rpcbind    4265  10 udp4   192.168.119.6:111     *:*
root     rpcbind    4265  11 udp4   *:768                 *:*
root     rpcbind    4265  12 tcp4   127.0.0.1:111         *:*
root     rpcbind    4265  13 tcp4   192.168.119.6:111     *:*

% uname -a
FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r239793: Wed 
Aug 29 03:00:30 SAMT 2012     bsam@bsam.wart.ru:/usr/obj/usr/src/sys/BBX 
  i386

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve

Comment 9 Eitan Adler 2012-11-13 20:52:19 UTC

State Changed
From-To: feedback->open

Submitter provided requested information 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117711 

Date: Wed, 27 Feb 2013 17:46:35 -0800

Hi,

I've just run into this issue under FreeBSD 10 - rpcbind '-h' provides a false sense of security, as by default although some of the ports it sets up do indeed bind to the requested IP - there's one or more random ports opened on UDP - that ignore the '-h' IP address, and are open to the world.

Is anyone able to look at this - this PR seems pretty ancient (filed in 2007, and the issue still kicking along in 2014? - 7 years?).

As the ports opened are random they are also hard to protect with ipfw - so all in all, it's a bit of a PITA :(

At the very least can someone flick it from 'Normal Affects Only Me' to 'Affects a Few people'?

-Karl

I just also encountered this on 10.0-RELEASE issue while setting up a jail. 7 years is a pretty long time...

Comment 12 Hiroki Sato 2014-10-18 17:24:24 UTC

I will look into this.

This issue came up tonight on #dragonflybsd on EFNet, since rpcbind on DragonflyBSD behaves the same.  I spent some time throwing in tons of debugging code to try and figure the cause.  I only did testing/checking with an IPv4-only system (IPv6 is completely removed from kernel/userland) so that may need additional testing.  Some details are below, mainly for Hiroki-san or whoever wants to tackle this.

IMPORTANT: I do not have much familiarity with RPC behaviour or design, so fixing this may or may not be proper when compared to what the RFC specifies.  I do not recommend fixing this until someone familiar with RPC and those RFCs is able to confirm that addressing this problem is acceptable.

The "mysterious UDP port" that's bound to INADDR_ANY, even when using rpcbind -h is caused by the call to create_rmtcall_fd() in rpcb_svc_com.c -- which only happens when nconf->nc_semantics == NC_TPI_CLTS (no clue what that is/means).

create_rmtcall_fd() makes a call to svc_tli_create() which is a libc function for making an RPC server handle.  It calls the function like so:

xprt = svc_tli_create(fd, 0, (struct t_bind *) 0, 0, 0);

Per man page:

     SVCXPRT *
     svc_tli_create(const int fildes, const struct netconfig *netconf,
         const struct t_bind *bindaddr, const u_int sendsz,
         const u_int recvsz);

     svc_tli_create()
            This routine creates an RPC server handle, and returns a pointer
            to it.  The fildes argument is the file descriptor on which the
            service is listening.  If fildes is RPC_ANYFD, it opens a file
            descriptor on the transport specified by netconf.  If the file
            descriptor is unbound and bindaddr is not NULL, fildes is bound to
            the address specified by bindaddr, otherwise fildes is bound to a
            default address chosen by the transport.

An fd is already allocated (so RPC_ANYFD is not used), netconf is not specified (NULL/0), and -- here's the cause -- bindaddr is NULL/0, which is why INADDR_ANY is being chosen.

Fixing this by passing create_rmtcall_fd() some stuff from outside of it (such as sa and addrlen) may be possible.

This is still present in 10.1-p3.

# procstat -c 452
  PID COMM             ARGS                                                 
  452 rpcbind          /usr/sbin/rpcbind -h 10.0.0.8

# procstat -f 452
  PID COMM               FD T V FLAGS     REF  OFFSET PRO NAME        
  452 rpcbind           text v r r-------  -       - -   /usr/sbin/rpcbind 
  452 rpcbind            cwd v d r-------  -       - -   /                 
  452 rpcbind           root v d r-------  -       - -   /                 
  452 rpcbind              0 v c rw------  3       0 -   /dev/null         
  452 rpcbind              1 v c rw------  3       0 -   /dev/null         
  452 rpcbind              2 v c rw------  3       0 -   /dev/null         
  452 rpcbind              3 v r r------l  1       0 -   -                 
  452 rpcbind              4 s - rw------  1       0 UDP ::.0 ::.0
  452 rpcbind              5 s - rw------  1       0 UDS /var/run/rpcbind.sock
  452 rpcbind              6 s - rw------  1       0 UDP ::1.111 ::.0
  452 rpcbind              7 s - rw------  1       0 UDP ::.961 ::.0
                                                         ^^^^^^^^^^^
  452 rpcbind              8 s - rw------  1       0 TCP ::1.111 ::.0
  452 rpcbind              9 s - rw------  1       0 UDP 127.0.0.1:111 0.0.0.0:0
  452 rpcbind             10 s - rw------  1       0 UDP 10.0.0.8:111 0.0.0.0:0
  452 rpcbind             11 s - rw------  1       0 UDP 0.0.0.0:903 0.0.0.0:0
                                                         ^^^^^^^^^^^
  452 rpcbind             12 s - rw------  1       0 TCP 127.0.0.1:111 0.0.0.0:0
  452 rpcbind             13 s - rw------  1       0 TCP 10.0.0.8:111 0.0.0.0:0

It is an interesting situation when you have both the host and a jail running NFS servers. I wonder what is rpcbind binding to the jail IP address causes any issues.

This is still present in 11.0-RELEASE-p1

root  675   0.0  0.0  10424  1912  -  Ss   22:48      0:00.05 /usr/sbin/rpcbind -h 10.141.254.2

root     rpcbind    675   4  udp6   *:*                   *:*
root     rpcbind    675   5  stream /var/run/rpcbind.sock
root     rpcbind    675   6  udp6   ::1:111               *:*
root     rpcbind    675   7  udp6   *:663                 *:*
root     rpcbind    675   8  tcp6   ::1:111               *:*
root     rpcbind    675   9  udp4   127.0.0.1:111         *:*
root     rpcbind    675   10 udp4   10.141.254.2:111      *:*
root     rpcbind    675   11 udp4   *:922                 *:*
root     rpcbind    675   12 tcp4   127.0.0.1:111         *:*
root     rpcbind    675   13 tcp4   10.141.254.2:111      *:*

The problem is, that rpcinfo  *always* binds to 127.0.0.1 and ::1, regardless whether you have given these with a "-h" option.

In a FreeBSD jail, binds to the loopback are always remapped to the primary jail address, and if this address is a public IP address, your jailed rpcbind will be available from extern!

Either rpcbind should detect that it is running inside a jail, and then skip the implicit binding to localhost.

Or, it should check whether the primary jail ip address is a public or private IP address and act accordingly (that is, not binding to 127.0.0.1 / ::1)

(In reply to Armin Gruner from comment #17)

The behaviour you see is documented:

rpcbind(8)
> Note that when specifying IP addresses with -h, rpcbind will automatically add 
> 127.0.0.1 and if IPv6 is enabled, ::1 to the list.

The actual topic of this PR is different: rpcbind binds to 0.0.0.0 even when a specific set of addresses is given as argument to -h. 

0.0.0.0 means ANY address, this must not be confused with the mapping that occurs for 127.0.0.1 (-> primary jail ip) in a jailed environment.

regards,
Robert Schulze

Whops, yes, I stand corrected. I may open another ticket for this.

Actually, I've worked around it by flipping the assignment of jail interfaces and adresses, if one uses a private IP address as the primary jail address, this one is used when 127.0.0.1 is remapped.

This is still present in 12.1-p10:

# grep rpcbind /etc/rc.conf
rpcbind_enable="YES"
rpcbind_flags="-h 10.10.1.40"

# ps auxwww | grep rpcbind
root   6191    0.0  0.0  11332  2792  -  Ss   16Sep20      1:19.83 /usr/sbin/rpcbind -h 10.10.1.40

# sockstat -l4 | grep rpcbind
root     rpcbind    6191  9  udp4   127.0.0.1:111         *:*
root     rpcbind    6191  10 udp4   10.10.1.40:111        *:*
root     rpcbind    6191  11 udp4   *:1011                *:*
root     rpcbind    6191  12 tcp4   127.0.0.1:111         *:*
root     rpcbind    6191  13 tcp4   10.10.1.40:111        *:*

Same issue here on stable/12:f2a88e744.