Re: RPC request sent to 127.0.0.1 becomes from other IP on machine

[Benjamin Kaduk]

On Thu, 10 Dec 2015, Rick Macklem wrote:

> Hi,
>
> Mark has reported a problem via email where the nfsuserd daemon sees
> requests coming from an IP# assigned to the machine instead of 127.0.0.1.
> Here's a snippet from his message:
>   Ok, I have Plex in a jail and when I scan the remote NFS file share the
>   *local* server's nfsuserd spams the logs.
> Spamming the logs refers to the messages nfsuserd generates when it gets
> a request from an address other than 127.0.0.1.
>
> I think the best solution is to switch nfsuserd over to using an AF_LOCAL
> socket like the gssd uses, but that will take a little coding and probably
> won't be MFCable.
>
> I've sent him the attached patch to try as a workaround.
>
> Does anyone happen to know under what circumstances the address 127.0.0.1
> gets replaced?

My memory is quite hazy on this subject, but I think that outbound traffic
from a jail is not permitted to use the system loopback address 127.0.0.1;
traffic from this address within a jail gets replace with the jail's
primary IP address.  It is possible to specify an alternate loopback
address for use within the jail (e.g., 127.0.0.2) and if that alternate
address is only bound within the jail, it can be used for outgoing traffic
to the host.  See jail.conf(5); I appear to have something like:

kduck {
host.hostname = "kduck.mit.edu";
ip4.addr = lo0|127.0.0.2, 18.18.0.52;
[...]
}

Note that there may be some additional magic about the primary address of
the jail being first (or last?) in the list of addresses.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RPC request sent to 127.0.0.1 becomes from other IP on machine

[Rick Macklem]

Ok, I had a hunch it was related to the use of jails.
I am just testing a patch that switches the nfsuserd over to
using an af_local socket, so this will be avoided.
(I think it makes more sense anyhow. I just never got around
 to doing it.;-)

Thanks for the info, rick

- Original Message -
> On Thu, 10 Dec 2015, Rick Macklem wrote:
> 
> > Hi,
> >
> > Mark has reported a problem via email where the nfsuserd daemon sees
> > requests coming from an IP# assigned to the machine instead of 127.0.0.1.
> > Here's a snippet from his message:
> >   Ok, I have Plex in a jail and when I scan the remote NFS file share the
> >   *local* server's nfsuserd spams the logs.
> > Spamming the logs refers to the messages nfsuserd generates when it gets
> > a request from an address other than 127.0.0.1.
> >
> > I think the best solution is to switch nfsuserd over to using an AF_LOCAL
> > socket like the gssd uses, but that will take a little coding and probably
> > won't be MFCable.
> >
> > I've sent him the attached patch to try as a workaround.
> >
> > Does anyone happen to know under what circumstances the address 127.0.0.1
> > gets replaced?
> 
> My memory is quite hazy on this subject, but I think that outbound traffic
> from a jail is not permitted to use the system loopback address 127.0.0.1;
> traffic from this address within a jail gets replace with the jail's
> primary IP address.  It is possible to specify an alternate loopback
> address for use within the jail (e.g., 127.0.0.2) and if that alternate
> address is only bound within the jail, it can be used for outgoing traffic
> to the host.  See jail.conf(5); I appear to have something like:
> 
> kduck {
> host.hostname = "kduck.mit.edu";
> ip4.addr = lo0|127.0.0.2, 18.18.0.52;
> [...]
> }
> 
> Note that there may be some additional magic about the primary address of
> the jail being first (or last?) in the list of addresses.
> 
> -Ben
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RPC request sent to 127.0.0.1 becomes from other IP on machine

[Rick Macklem]

Hi,

Mark has reported a problem via email where the nfsuserd daemon sees
requests coming from an IP# assigned to the machine instead of 127.0.0.1.
Here's a snippet from his message:
  Ok, I have Plex in a jail and when I scan the remote NFS file share the
  *local* server's nfsuserd spams the logs.
Spamming the logs refers to the messages nfsuserd generates when it gets
a request from an address other than 127.0.0.1.

I think the best solution is to switch nfsuserd over to using an AF_LOCAL
socket like the gssd uses, but that will take a little coding and probably
won't be MFCable.

I've sent him the attached patch to try as a workaround.

Does anyone happen to know under what circumstances the address 127.0.0.1
gets replaced?

And do you know if it will always be replaced with the same
address?
(I'm basically wondering if the workaround needs to be a list of IP addresses
 instead of a single address?)

Thanks in advance for any help with this, rick

--- nfsuserd.c.sav	2015-12-09 18:46:29.284972000 -0500
+++ nfsuserd.c	2015-12-09 18:59:33.564498000 -0500
@@ -40,6 +40,10 @@ __FBSDID("$FreeBSD: head/usr.sbin/nfsuse
 #include 
 #include 
 
+#include 
+
+#include 
+
 #include 
 
 #include 
@@ -94,6 +98,7 @@ gid_t defaultgid = (gid_t)32767;
 int verbose = 0, im_a_slave = 0, nfsuserdcnt = -1, forcestart = 0;
 int defusertimeout = DEFUSERTIMEOUT, manage_gids = 0;
 pid_t slaves[MAXNFSUSERD];
+struct in_addr fromip;
 
 int
 main(int argc, char *argv[])
@@ -144,6 +149,7 @@ main(int argc, char *argv[])
 			}
 		}
 	}
+	fromip.s_addr = inet_addr("127.0.0.1");
 	nid.nid_usermax = DEFUSERMAX;
 	nid.nid_usertimeout = defusertimeout;
 
@@ -190,6 +196,15 @@ main(int argc, char *argv[])
 usage();
 			}
 			nid.nid_usertimeout = defusertimeout = i * 60;
+		} else if (!strcmp(*argv, "-fromip")) {
+			if (argc == 1)
+usage();
+			argc--;
+			argv++;
+			if (inet_aton(*argv, ) == 0) {
+fprintf(stderr, "Bad -fromip %s\n", *argv);
+usage();
+			}
 		} else if (nfsuserdcnt == -1) {
 			nfsuserdcnt = atoi(*argv);
 			if (nfsuserdcnt < 1)
@@ -458,22 +473,22 @@ nfsuserdsrv(struct svc_req *rqstp, SVCXP
 	u_short sport;
 	struct info info;
 	struct nfsd_idargs nid;
-	u_int32_t saddr;
 	gid_t grps[NGROUPS];
 	int ngroup;
 
 	/*
-	 * Only handle requests from 127.0.0.1 on a reserved port number.
+	 * Only handle requests from 127.0.0.1 on a reserved port number,
+	 * unless the "-fromip" specified a different address.
 	 * (Since a reserved port # at localhost implies a client with
 	 *  local root, there won't be a security breach. This is about
 	 *  the only case I can think of where a reserved port # means
 	 *  something.)
 	 */
 	sport = ntohs(transp->xp_raddr.sin_port);
-	saddr = ntohl(transp->xp_raddr.sin_addr.s_addr);
 	if ((rqstp->rq_proc != NULLPROC && sport >= IPPORT_RESERVED) ||
-	saddr != 0x7f01) {
-		syslog(LOG_ERR, "req from ip=0x%x port=%d\n", saddr, sport);
+	transp->xp_raddr.sin_addr.s_addr != fromip.s_addr) {
+		syslog(LOG_ERR, "req from ip=%s port=%d\n",
+		inet_ntoa(transp->xp_raddr.sin_addr), sport);
 		svcerr_weakauth(transp);
 		return;
 	}
@@ -721,5 +736,5 @@ usage(void)
 {
 
 	errx(1,
-	"usage: nfsuserd [-usermax cache_size] [-usertimeout minutes] [-verbose] [-manage-gids] [-domain domain_name] [n]");
+	"usage: nfsuserd [-usermax cache_size] [-usertimeout minutes] [-verbose] [-manage-gids] [-domain domain_name] [-fromip xx.xx.xx.xx] [n]");
 }
--- nfsuserd.8.sav	2015-12-09 19:13:48.173812000 -0500
+++ nfsuserd.8	2015-12-09 19:19:38.522516000 -0500
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD: head/usr.sbin/nfsuserd/nfsuserd.8 276258 2014-12-26 21:56:23Z joel $
 .\"
-.Dd November 1, 2015
+.Dd December 9, 2015
 .Dt NFSUSERD 8
 .Os
 .Sh NAME
@@ -37,6 +37,7 @@ services plus support manage-gids for al
 .Op Fl domain Ar domain_name
 .Op Fl usertimeout Ar minutes
 .Op Fl usermax Ar max_cache_size
+.Op Fl fromip Ar ip_address
 .Op Fl verbose
 .Op Fl force
 .Op Fl manage-gids
@@ -76,6 +77,21 @@ the more kernel memory is used, but the 
 system can afford the memory use, make this the sum of the number of
 entries in your group and password databases.
 The default is 200 entries.
+.It Fl fromip Ar ip_address
+This overrides the default upcall from address of 127.0.0.1.
+Although the upcall connection is done to 127.0.0.1, some network
+configurations will result in another IP address assigned to the machine
+as the from address.
+If you get syslog messages like:
+.sp
+.nf
+Dec  9 19:03:20 nfsv4-laptop nfsuserd:[506]: req from ip=131.104.48.17 port=861
+.fi
+.sp
+then you should use this option to set the from IP address to the one in
+the message.
+Only do this for IP addresses assigned to the machine this daemon is running
+on.
 .It Fl verbose
 When set, the server logs a bunch of information to syslog.
 .It Fl force
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any 

Re: RPC request sent to 127.0.0.1 becomes from other IP on machine

[Doug Rabson]

I think a local socket is probably the best solution long term. Using a
local socket also allows using filesystem permissions to control access
which is required for gssd but not necessarily for nfsuserd.


On 10 December 2015 at 13:37, Rick Macklem  wrote:

> Hi,
>
> Mark has reported a problem via email where the nfsuserd daemon sees
> requests coming from an IP# assigned to the machine instead of 127.0.0.1.
> Here's a snippet from his message:
>   Ok, I have Plex in a jail and when I scan the remote NFS file share the
>   *local* server's nfsuserd spams the logs.
> Spamming the logs refers to the messages nfsuserd generates when it gets
> a request from an address other than 127.0.0.1.
>
> I think the best solution is to switch nfsuserd over to using an AF_LOCAL
> socket like the gssd uses, but that will take a little coding and probably
> won't be MFCable.
>
> I've sent him the attached patch to try as a workaround.
>
> Does anyone happen to know under what circumstances the address 127.0.0.1
> gets replaced?
>
> And do you know if it will always be replaced with the same
> address?
> (I'm basically wondering if the workaround needs to be a list of IP
> addresses
>  instead of a single address?)
>
> Thanks in advance for any help with this, rick
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RPC request sent to 127.0.0.1 becomes from other IP on machine

[Mark Felder]

On Thu, Dec 10, 2015, at 07:37, Rick Macklem wrote:
> Hi,
> 
> Mark has reported a problem via email where the nfsuserd daemon sees
> requests coming from an IP# assigned to the machine instead of 127.0.0.1.
> Here's a snippet from his message:
>   Ok, I have Plex in a jail and when I scan the remote NFS file share the
>   *local* server's nfsuserd spams the logs.
> Spamming the logs refers to the messages nfsuserd generates when it gets
> a request from an address other than 127.0.0.1.
> 
> I think the best solution is to switch nfsuserd over to using an AF_LOCAL
> socket like the gssd uses, but that will take a little coding and
> probably
> won't be MFCable.
> 
> I've sent him the attached patch to try as a workaround.
> 
> Does anyone happen to know under what circumstances the address 127.0.0.1
> gets replaced?
> 
> And do you know if it will always be replaced with the same
> address?
> (I'm basically wondering if the workaround needs to be a list of IP
> addresses
>  instead of a single address?)
> 
> Thanks in advance for any help with this, rick
> 

I've opened a PR per your request

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205193

-- 
  Mark Felder
  ports-secteam member
  f...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"