linux-kernel - Re: [REGRESSION] NFS is creating a hidden port (left over from xs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Jun 2015 21:37:02 -0400
From:	Jeff Layton <jlayton@...chiereds.net>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Trond Myklebust <trond.myklebust@...marydata.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux Network Devel Mailing List <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, bfields@...ldses.org
Subject: Re: [REGRESSION] NFS is creating a hidden port (left over from
 xs_bind() )

On Thu, 18 Jun 2015 21:08:43 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu, 18 Jun 2015 18:50:51 -0400
> Jeff Layton <jlayton@...chiereds.net> wrote:
>  
> > The interesting bit here is that the sockets all seem to connect to port
> > 55201 on the remote host, if I'm reading these traces correctly. What's
> > listening on that port on the server?
> > 
> > This might give some helpful info:
> > 
> >     $ rpcinfo -p <NFS servername>
> 
> # rpcinfo -p wife
>    program vers proto   port  service
>     100000    4   tcp    111  portmapper
>     100000    3   tcp    111  portmapper
>     100000    2   tcp    111  portmapper
>     100000    4   udp    111  portmapper
>     100000    3   udp    111  portmapper
>     100000    2   udp    111  portmapper
>     100024    1   udp  34243  status
>     100024    1   tcp  34498  status
> 
> # rpcinfo -p localhost
>    program vers proto   port  service
>     100000    4   tcp    111  portmapper
>     100000    3   tcp    111  portmapper
>     100000    2   tcp    111  portmapper
>     100000    4   udp    111  portmapper
>     100000    3   udp    111  portmapper
>     100000    2   udp    111  portmapper
>     100024    1   udp  38332  status
>     100024    1   tcp  52684  status
>     100003    2   tcp   2049  nfs
>     100003    3   tcp   2049  nfs
>     100003    4   tcp   2049  nfs
>     100227    2   tcp   2049
>     100227    3   tcp   2049
>     100003    2   udp   2049  nfs
>     100003    3   udp   2049  nfs
>     100003    4   udp   2049  nfs
>     100227    2   udp   2049
>     100227    3   udp   2049
>     100021    1   udp  53218  nlockmgr
>     100021    3   udp  53218  nlockmgr
>     100021    4   udp  53218  nlockmgr
>     100021    1   tcp  49825  nlockmgr
>     100021    3   tcp  49825  nlockmgr
>     100021    4   tcp  49825  nlockmgr
>     100005    1   udp  49166  mountd
>     100005    1   tcp  48797  mountd
>     100005    2   udp  47856  mountd
>     100005    2   tcp  53839  mountd
>     100005    3   udp  36090  mountd
>     100005    3   tcp  46390  mountd
> 
> Note, the box has been rebooted since I posted my last trace.
> 

Ahh pity. The port has probably changed...if you trace it again maybe
try to figure out what it's talking to before rebooting the server?

> > 
> > Also, what NFS version are you using to mount here? Your fstab entries
> > suggest that you're using the default version (for whatever distro this
> > is), but have you (e.g.) set up nfsmount.conf to default to v3 on this
> > box?
> > 
> 
> My box is Debian testing (recently updated).
> 
> # dpkg -l nfs-*
> 
> ii  nfs-common     1:1.2.8-9    amd64        NFS support files common to clien
> ii  nfs-kernel-ser 1:1.2.8-9    amd64        support for NFS kernel server
> 
> 
> same for both boxes.
> 
> nfsmount.conf doesn't exist on either box.
> 
> I'm assuming it is using nfs4.
> 

(cc'ing Bruce)

Oh! I was thinking that you were seeing this extra port on the
_client_, but now rereading your original mail I see that it's
appearing up on the NFS server. Is that correct?

So, assuming that this is NFSv4.0, then this port is probably bound
when the server is establishing the callback channel to the client. So
we may need to look at how those xprts are being created and whether
there are differences from a standard client xprt.

-- 
Jeff Layton <jlayton@...chiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/