proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Hi,

The current rpcbind -i option seems to relax 3 different security requirements.
If the user wants to allow any one of the three, he is forced to allow
all 3.

The attached patch introduces 3 new options (-c, -r, and -u) to break this
down to give the user control of which security requirements to relax.

This patch compiles, but has not been tested yet.  If there is any
interest in accepting this, I will of course test it. :-)  But it's fairly
basic, so I thought I'd gauge the interest level first.  Steve
Dickson from Redhat suggested that I post here to discuss this issue
regarding https://bugzilla.redhat.com/show_bug.cgi?id=481422

Thank you for considering this.  I do not follow this list, so apologize
in advance if this email violates any conventions or protocols.

Regards,
Andy

[-- Attachment #2: rpcbind-0.2.0-security.patch --]
[-- Type: text/plain, Size: 6365 bytes --]

diff -up rpcbind-0.2.0/src/rpcbind.c.orig rpcbind-0.2.0/src/rpcbind.c
--- rpcbind-0.2.0/src/rpcbind.c.orig	2009-05-29 09:38:22.000000000 -0400
+++ rpcbind-0.2.0/src/rpcbind.c	2010-12-09 15:39:14.459781896 -0500
@@ -92,8 +92,9 @@ char *rpcbinduser = NULL;
 #define RPCBINDDLOCK "/var/run/rpcbind.lock"
 
 int runasdaemon = 0;
-int insecure = 0;
-int oldstyle_local = 0;
+int allow_remote = 0;
+int allow_unprivileged = 0;
+int allow_callit = 0;
 int verboselog = 0;
 
 char **hosts = NULL;
@@ -730,13 +731,15 @@ static void
 parseargs(int argc, char *argv[])
 {
 	int c;
-	oldstyle_local = 1;
-	while ((c = getopt(argc, argv, "dwah:ils")) != -1) {
+	while ((c = getopt(argc, argv, "acdh:ilrsuw")) != -1) {
 		switch (c) {
 		case 'a':
 			doabort = 1;	/* when debugging, do an abort on */
 			break;		/* errors; for rpcbind developers */
 					/* only! */
+		case 'c':
+			allow_callit = 1;
+			break;
 		case 'd':
 			debugging = 1;
 			break;
@@ -750,21 +753,27 @@ parseargs(int argc, char *argv[])
 				errx(1, "Out of memory");
 			break;
 		case 'i':
-			insecure = 1;
+			allow_remote = allow_unprivileged = allow_callit = 1;
 			break;
 		case 'l':
 			verboselog = 1;
 			break;
+		case 'r':
+			allow_remote = 1;
+			break;
 		case 's':
 			runasdaemon = 1;
 			break;
+		case 'u':
+			allow_unprivileged = 1;
+			break;
 #ifdef WARMSTART
 		case 'w':
 			warmstart = 1;
 			break;
 #endif
 		default:	/* error */
-			fprintf(stderr,	"usage: rpcbind [-Idwils]\n");
+			fprintf(stderr,	"usage: rpcbind [-acdhilrsuw]\n");
 			exit (1);
 		}
 	}
diff -up rpcbind-0.2.0/src/rpcbind.h.orig rpcbind-0.2.0/src/rpcbind.h
--- rpcbind-0.2.0/src/rpcbind.h.orig	2009-05-29 09:38:22.000000000 -0400
+++ rpcbind-0.2.0/src/rpcbind.h	2010-12-09 15:37:47.340843901 -0500
@@ -67,8 +67,9 @@ struct r_rmtcall_args {
 extern int debugging;
 extern int doabort;
 extern int verboselog;
-extern int insecure;
-extern int oldstyle_local;
+extern int allow_remote;
+extern int allow_unprivileged;
+extern int allow_callit;
 extern rpcblist_ptr list_rbl;	/* A list of version 3 & 4 rpcbind services */
 
 #ifdef PORTMAP
@@ -123,6 +124,7 @@ int check_access(SVCXPRT *, rpcproc_t, v
 int check_callit(SVCXPRT *, struct r_rmtcall_args *, int);
 void logit(int, struct sockaddr *, rpcproc_t, rpcprog_t, const char *);
 int is_loopback(struct netbuf *);
+int is_privileged(struct netbuf *);
 int is_localroot(struct netbuf *);
 
 #ifdef PORTMAP
diff -up rpcbind-0.2.0/src/security.c.orig rpcbind-0.2.0/src/security.c
--- rpcbind-0.2.0/src/security.c.orig	2009-05-29 09:38:22.000000000 -0400
+++ rpcbind-0.2.0/src/security.c	2010-12-09 15:37:57.152719027 -0500
@@ -90,7 +90,7 @@ check_access(SVCXPRT *xprt, rpcproc_t pr
 		}
 		if (proc == RPCBPROC_GETADDR)
 			break;
-		if (!insecure && !is_loopback(caller)) {
+		if (!allow_remote && !is_loopback(caller)) {
 #ifdef RPCBIND_DEBUG
 			  if (debugging)
 			    fprintf(stderr, " declined (non-loopback sender) \n");
@@ -100,6 +100,16 @@ check_access(SVCXPRT *xprt, rpcproc_t pr
 				    " declined (non-loopback sender)");
 			return 0;
 		}
+		if (!allow_unprivileged && !is_privileged(caller)) {
+#ifdef RPCBIND_DEBUG
+			  if (debugging)
+			    fprintf(stderr, " declined (non-privileged sender) \n");
+#endif
+			if (verboselog)
+				logit(log_severity, addr, proc, prog,
+				    " declined (non-privileged sender)");
+			return 0;
+		}
 		break;
 	case RPCBPROC_CALLIT:
 	case RPCBPROC_INDIRECT:
@@ -141,32 +151,65 @@ is_loopback(struct netbuf *nbuf)
 
 	switch (addr->sa_family) {
 	case AF_INET:
-		if (!oldstyle_local)
-			return 0;
 		sin = (struct sockaddr_in *)addr;
 #ifdef RPCBIND_DEBUG
 		if (debugging)
 			  fprintf(stderr,
-				  "Checking caller's adress (port = %d)\n",
+				  "Checking caller's address (port = %d)\n",
 				  ntohs(sin->sin_port));
 #endif
-	       	return ((sin->sin_addr.s_addr == htonl(INADDR_LOOPBACK)) &&
-		    (ntohs(sin->sin_port) < IPPORT_RESERVED));
+	       	return (sin->sin_addr.s_addr == htonl(INADDR_LOOPBACK));
 #ifdef INET6
 	case AF_INET6:
-		if (!oldstyle_local)
-			return 0;
 		sin6 = (struct sockaddr_in6 *)addr;
 #ifdef RPCBIND_DEBUG
 		if (debugging)
 			  fprintf(stderr,
-				  "Checking caller's adress (port = %d)\n",
+				  "Checking caller's address (port = %d)\n",
 				  ntohs(sin6->sin6_port));
 #endif
-		return ((IN6_IS_ADDR_LOOPBACK(&sin6->sin6_addr) ||
-			 (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr) &&
-			  sin6->sin6_addr.s6_addr32[3] == htonl(INADDR_LOOPBACK))) &&
-		        (ntohs(sin6->sin6_port) < IPV6PORT_RESERVED));
+		return (IN6_IS_ADDR_LOOPBACK(&sin6->sin6_addr) ||
+			(IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr) &&
+			 sin6->sin6_addr.s6_addr32[3] == htonl(INADDR_LOOPBACK)));
+#endif
+	case AF_LOCAL:
+		return 1;
+	default:
+		break;
+	}
+	
+	return 0;
+}
+
+int
+is_privileged(struct netbuf *nbuf)
+{
+	struct sockaddr *addr = (struct sockaddr *)nbuf->buf;
+	struct sockaddr_in *sin;
+#ifdef INET6
+	struct sockaddr_in6 *sin6;
+#endif
+
+	switch (addr->sa_family) {
+	case AF_INET:
+		sin = (struct sockaddr_in *)addr;
+#ifdef RPCBIND_DEBUG
+		if (debugging)
+			  fprintf(stderr,
+				  "Checking caller's port (%d)\n",
+				  ntohs(sin->sin_port));
+#endif
+	       	return (ntohs(sin->sin_port) < IPPORT_RESERVED);
+#ifdef INET6
+	case AF_INET6:
+		sin6 = (struct sockaddr_in6 *)addr;
+#ifdef RPCBIND_DEBUG
+		if (debugging)
+			  fprintf(stderr,
+				  "Checking caller's port (%d)\n",
+				  ntohs(sin6->sin6_port));
+#endif
+		return (ntohs(sin6->sin6_port) < IPV6PORT_RESERVED);
 #endif
 	case AF_LOCAL:
 		return 1;
@@ -192,15 +235,11 @@ is_localroot(struct netbuf *nbuf)
 
 	switch (addr->sa_family) {
 	case AF_INET:
-		if (!oldstyle_local)
-			return 0;
 		sin = (struct sockaddr_in *)addr;
 		return ((sin->sin_addr.s_addr == htonl(INADDR_LOOPBACK)) &&
 		    (ntohs(sin->sin_port) < IPPORT_RESERVED));
 #ifdef INET6
 	case AF_INET6:
-		if (!oldstyle_local)
-			return 0;
 		sin6 = (struct sockaddr_in6 *)addr;
 		return ((IN6_IS_ADDR_LOOPBACK(&sin6->sin6_addr) ||
 			 (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr) &&
@@ -310,11 +349,7 @@ check_callit(SVCXPRT *xprt, struct r_rmt
 	 */
 	switch (args->rmt_prog) {
 	case RPCBPROG:
-		/*
-		 * Allow indirect calls to ourselves in insecure mode.
-		 * The is_loopback checks aren't useful then anyway.
-		 */
-		if (!insecure)
+		if (!allow_callit)
 			goto deny;
 		break;
 	case MOUNTPROG:

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 9, 2010, at 3:49 PM, Andrew J. Schorr wrote:

> Hi,
> 
> The current rpcbind -i option seems to relax 3 different security requirements.
> If the user wants to allow any one of the three, he is forced to allow
> all 3.
> 
> The attached patch introduces 3 new options (-c, -r, and -u) to break this
> down to give the user control of which security requirements to relax.
> 
> This patch compiles, but has not been tested yet.  If there is any
> interest in accepting this, I will of course test it. :-)  But it's fairly
> basic, so I thought I'd gauge the interest level first.  Steve
> Dickson from Redhat suggested that I post here to discuss this issue
> regarding https://bugzilla.redhat.com/show_bug.cgi?id=481422

Looking over the bug...

It sounds like your application is trying to use glibc's RPC implementation with rpcbind.  If you build your application with libtirpc instead, it should use an AF_UNIX socket to contact rpcbind instead of loopback.  The AF_UNIX socket carries some authentication information with the registration request.  All users of your application would be allowed to set or unset RPC registrations in that case.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Steve Dickson]

On 12/09/2010 04:41 PM, Chuck Lever wrote:
> 
> On Dec 9, 2010, at 3:49 PM, Andrew J. Schorr wrote:
> 
>> Hi,
>>
>> The current rpcbind -i option seems to relax 3 different security requirements.
>> If the user wants to allow any one of the three, he is forced to allow
>> all 3.
>>
>> The attached patch introduces 3 new options (-c, -r, and -u) to break this
>> down to give the user control of which security requirements to relax.
>>
>> This patch compiles, but has not been tested yet.  If there is any
>> interest in accepting this, I will of course test it. :-)  But it's fairly
>> basic, so I thought I'd gauge the interest level first.  Steve
>> Dickson from Redhat suggested that I post here to discuss this issue
>> regarding https://bugzilla.redhat.com/show_bug.cgi?id=481422
> 
> Looking over the bug...
> 
> It sounds like your application is trying to use glibc's RPC 
> implementation with rpcbind.  If you build your application with 
> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
> instead of loopback.  The AF_UNIX socket carries some authentication 
> information with the registration request.  All users of your 
> application would be allowed to set or unset RPC registrations 
> in that case.
> 
I was under the impression rebuilding the applications was not
possible... but maybe I misunderstood... 

But in the end, I guess I'm not against having functionality 
like this... If it make it easier for people to port legacy
applications to Linux, its probably a good thing... 

steved.

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
> 
> 
> On 12/09/2010 04:41 PM, Chuck Lever wrote:
> > It sounds like your application is trying to use glibc's RPC 
> > implementation with rpcbind.  If you build your application with 
> > libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
> > instead of loopback.  The AF_UNIX socket carries some authentication 
> > information with the registration request.  All users of your 
> > application would be allowed to set or unset RPC registrations 
> > in that case.

I think you are correct.  This is probably due to some combination
of ignorance and stupidity on my part.  I didn't realize that libtirpc
was a drop-in replacement for the glibc RPC routines.

> I was under the impression rebuilding the applications was not
> possible... but maybe I misunderstood... 

Rebuilding should be possible, I need to look into this.

> But in the end, I guess I'm not against having functionality 
> like this... If it make it easier for people to port legacy
> applications to Linux, its probably a good thing... 

I think the patch does add more control over rpcbind behavior, but I
grant that it may be less interesting if nobody is using IP to connect
from local clients.  Nonetheless, it still adds the ability to have
separate control over whether to accept remote set/unset calls and
whether to honor indirect/callit calls.  Unless I'm mistaken, this is
still relevant even if libtirpc is used.

So I would argue that the patch is still a good thing, but I agree that
I should relink my code with libtirpc.

Regards,
Andy

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Steve Dickson]

On 12/09/2010 09:38 PM, Andrew J. Schorr wrote:
> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>>
>>
>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>> It sounds like your application is trying to use glibc's RPC 
>>> implementation with rpcbind.  If you build your application with 
>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>> information with the registration request.  All users of your 
>>> application would be allowed to set or unset RPC registrations 
>>> in that case.
> 
> I think you are correct.  This is probably due to some combination
> of ignorance and stupidity on my part.  I didn't realize that libtirpc
> was a drop-in replacement for the glibc RPC routines.
> 
>> I was under the impression rebuilding the applications was not
>> possible... but maybe I misunderstood... 
> 
> Rebuilding should be possible, I need to look into this.
> 
>> But in the end, I guess I'm not against having functionality 
>> like this... If it make it easier for people to port legacy
>> applications to Linux, its probably a good thing... 
> 
> I think the patch does add more control over rpcbind behavior, but I
> grant that it may be less interesting if nobody is using IP to connect
> from local clients.  Nonetheless, it still adds the ability to have
> separate control over whether to accept remote set/unset calls and
> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
> still relevant even if libtirpc is used.
> 
> So I would argue that the patch is still a good thing, but I agree that
> I should relink my code with libtirpc.
If you decide to officially resubmit the patch please
1) Please sign you patch with a  Signed-off-by: line as
    described in: 
      http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches

2) Also include a separate patch that updates the manual page.
   (I can help with the nroff formatting). 

tia,

steved.

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote:

> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>> 
>> 
>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>> It sounds like your application is trying to use glibc's RPC 
>>> implementation with rpcbind.  If you build your application with 
>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>> information with the registration request.  All users of your 
>>> application would be allowed to set or unset RPC registrations 
>>> in that case.
> 
> I think you are correct.  This is probably due to some combination
> of ignorance and stupidity on my part.  I didn't realize that libtirpc
> was a drop-in replacement for the glibc RPC routines.
> 
>> I was under the impression rebuilding the applications was not
>> possible... but maybe I misunderstood... 
> 
> Rebuilding should be possible, I need to look into this.
> 
>> But in the end, I guess I'm not against having functionality 
>> like this... If it make it easier for people to port legacy
>> applications to Linux, its probably a good thing... 
> 
> I think the patch does add more control over rpcbind behavior, but I
> grant that it may be less interesting if nobody is using IP to connect
> from local clients.  Nonetheless, it still adds the ability to have
> separate control over whether to accept remote set/unset calls and
> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
> still relevant even if libtirpc is used.

Not to put to fine a point on it, but we discourage the use of indirect RPC calls.  It's a well-known security hole.  Also, allowing anyone to set and unset RPC registrations is also insecure, and is discouraged.

In general we want people to switch to using AF_UNIX for local registrations, as that is secure from remote attack, and allows rpcbind to assign ownership of the registration so that only the user who registered that service may unregister it.

> So I would argue that the patch is still a good thing, but I agree that
> I should relink my code with libtirpc.

IMO we shouldn't add features that encourage people to configure rpcbind insecurely, especially when there are reasonable alternatives.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

On Fri, Dec 10, 2010 at 10:31:52AM -0500, Chuck Lever wrote:
> 
> Not to put to fine a point on it, but we discourage the use of indirect RPC calls.  It's a well-known security hole.  Also, allowing anyone to set and unset RPC registrations is also insecure, and is discouraged.
> 
> In general we want people to switch to using AF_UNIX for local registrations, as that is secure from remote attack, and allows rpcbind to assign ownership of the registration so that only the user who registered that service may unregister it.
> 
> > So I would argue that the patch is still a good thing, but I agree that
> > I should relink my code with libtirpc.
> 
> IMO we shouldn't add features that encourage people to configure rpcbind insecurely, especially when there are reasonable alternatives.

Well, if the patch won't be accepted, I will not put any more time into it.

But I do have one question: if glibc's RPC routines are deprecated in favor of
libtirpc, why not either remove the RPC code from glibc or at least mark these
functions deprecated so that people get warning messages when they rebuild code
(i.e. use __attribute__ (( __deprecated__ )) for all the functions declared in
/usr/include/rpc/*.h)?  There does not seem to be great documentation about
this change for ignorant users such as myself (who just upgraded Fedora
distros and unknowingly relinked with glibc instead of libtirpc).

Regards,
Andy

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Steve Dickson]

On 12/10/2010 10:31 AM, Chuck Lever wrote:
> 
> On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote:
> 
>> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>>>
>>>
>>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>>> It sounds like your application is trying to use glibc's RPC 
>>>> implementation with rpcbind.  If you build your application with 
>>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>>> information with the registration request.  All users of your 
>>>> application would be allowed to set or unset RPC registrations 
>>>> in that case.
>>
>> I think you are correct.  This is probably due to some combination
>> of ignorance and stupidity on my part.  I didn't realize that libtirpc
>> was a drop-in replacement for the glibc RPC routines.
>>
>>> I was under the impression rebuilding the applications was not
>>> possible... but maybe I misunderstood... 
>>
>> Rebuilding should be possible, I need to look into this.
>>
>>> But in the end, I guess I'm not against having functionality 
>>> like this... If it make it easier for people to port legacy
>>> applications to Linux, its probably a good thing... 
>>
>> I think the patch does add more control over rpcbind behavior, but I
>> grant that it may be less interesting if nobody is using IP to connect
>> from local clients.  Nonetheless, it still adds the ability to have
>> separate control over whether to accept remote set/unset calls and
>> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
>> still relevant even if libtirpc is used.
> 
> Not to put to fine a point on it, but we discourage the use of 
> indirect RPC calls.  It's a well-known security hole.  Also, 
> allowing anyone to set and unset RPC registrations is also 
> insecure, and is discouraged.
True... but its been this way for years... and always will be... 
 
> 
> In general we want people to switch to using AF_UNIX for local 
> registrations, as that is secure from remote attack, and allows 
> rpcbind to assign ownership of the registration so that only the 
> user who registered that service may unregister it.
If the option of rebuilding is available, yes, people should
switch to libtirpc... 

> 
>> So I would argue that the patch is still a good thing, but I agree that
>> I should relink my code with libtirpc.
> 
> IMO we shouldn't add features that encourage people to configure 
> rpcbind insecurely, especially when there are reasonable alternatives.
The -i is already a securely hole... So if we are concern about it
we should get ride of the -i completely... Or make it a useful 
securely hole... ;-)

The point of this patch was to make it easier for people 
to port legacy applications to Linux... If this indeed 
is the case, I think that overrides these (self induced) 
security issues... 

steved.
 

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 10, 2010, at 10:37 AM, Andrew J. Schorr wrote:

> On Fri, Dec 10, 2010 at 10:31:52AM -0500, Chuck Lever wrote:
>> 
>> Not to put to fine a point on it, but we discourage the use of indirect RPC calls.  It's a well-known security hole.  Also, allowing anyone to set and unset RPC registrations is also insecure, and is discouraged.
>> 
>> In general we want people to switch to using AF_UNIX for local registrations, as that is secure from remote attack, and allows rpcbind to assign ownership of the registration so that only the user who registered that service may unregister it.
>> 
>>> So I would argue that the patch is still a good thing, but I agree that
>>> I should relink my code with libtirpc.
>> 
>> IMO we shouldn't add features that encourage people to configure rpcbind insecurely, especially when there are reasonable alternatives.
> 
> Well, if the patch won't be accepted, I will not put any more time into it.

To be clear, I'm not the rpcbind maintainer, so Steve can decide to take a patch anyway.

> But I do have one question: if glibc's RPC routines are deprecated in favor of
> libtirpc, why not either remove the RPC code from glibc or at least mark these
> functions deprecated so that people get warning messages when they rebuild code
> (i.e. use __attribute__ (( __deprecated__ )) for all the functions declared in
> /usr/include/rpc/*.h)?  There does not seem to be great documentation about
> this change for ignorant users such as myself (who just upgraded Fedora
> distros and unknowingly relinked with glibc instead of libtirpc).

Welcome to Linux.  Changing glibc is viewed by some as an exceptionally challenging political task, which is why RPC hasn't been removed from it.  I quite agree that now that we have libtirpc, RPC should be removed from glibc.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

Hi Steve-

On Dec 10, 2010, at 10:55 AM, Steve Dickson wrote:

> On 12/10/2010 10:31 AM, Chuck Lever wrote:
>> 
>> On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote:
>> 
>>> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>>>> 
>>>> 
>>>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>>>> It sounds like your application is trying to use glibc's RPC 
>>>>> implementation with rpcbind.  If you build your application with 
>>>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>>>> information with the registration request.  All users of your 
>>>>> application would be allowed to set or unset RPC registrations 
>>>>> in that case.
>>> 
>>> I think you are correct.  This is probably due to some combination
>>> of ignorance and stupidity on my part.  I didn't realize that libtirpc
>>> was a drop-in replacement for the glibc RPC routines.
>>> 
>>>> I was under the impression rebuilding the applications was not
>>>> possible... but maybe I misunderstood... 
>>> 
>>> Rebuilding should be possible, I need to look into this.
>>> 
>>>> But in the end, I guess I'm not against having functionality 
>>>> like this... If it make it easier for people to port legacy
>>>> applications to Linux, its probably a good thing... 
>>> 
>>> I think the patch does add more control over rpcbind behavior, but I
>>> grant that it may be less interesting if nobody is using IP to connect
>>> from local clients.  Nonetheless, it still adds the ability to have
>>> separate control over whether to accept remote set/unset calls and
>>> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
>>> still relevant even if libtirpc is used.
>> 
>> Not to put to fine a point on it, but we discourage the use of 
>> indirect RPC calls.  It's a well-known security hole.  Also, 
>> allowing anyone to set and unset RPC registrations is also 
>> insecure, and is discouraged.
> True... but its been this way for years... and always will be... 
> 
>> In general we want people to switch to using AF_UNIX for local 
>> registrations, as that is secure from remote attack, and allows 
>> rpcbind to assign ownership of the registration so that only the 
>> user who registered that service may unregister it.
> If the option of rebuilding is available, yes, people should
> switch to libtirpc... 

Andrew makes a good point.  There would be no "switch to libtirpc" if distributions had a single RPC implementation.

Is there a good reason we still have the glibc RPC implementation?  We've resolved the licensing issue already, so there's nothing stopping any Linux distribution from adding a libtirpc package.

> 
>>> So I would argue that the patch is still a good thing, but I agree that
>>> I should relink my code with libtirpc.
>> 
>> IMO we shouldn't add features that encourage people to configure 
>> rpcbind insecurely, especially when there are reasonable alternatives.
> The -i is already a securely hole... So if we are concern about it
> we should get ride of the -i completely... Or make it a useful 
> securely hole... ;-)
> 
> The point of this patch was to make it easier for people 
> to port legacy applications to Linux... If this indeed 
> is the case, I think that overrides these (self induced) 
> security issues... 

If we go with just the evidence at hand: Andrew says he can rebuild his application.  Thus, so far there is no specific requirement to expand "-i".  IMO we should wait until there is, in the most noble of Linux traditions.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Steve Dickson]

On 12/10/2010 12:01 PM, Chuck Lever wrote:
> Hi Steve-
> 
> On Dec 10, 2010, at 10:55 AM, Steve Dickson wrote:
> 
>> On 12/10/2010 10:31 AM, Chuck Lever wrote:
>>>
>>> On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote:
>>>
>>>> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>>>>>
>>>>>
>>>>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>>>>> It sounds like your application is trying to use glibc's RPC 
>>>>>> implementation with rpcbind.  If you build your application with 
>>>>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>>>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>>>>> information with the registration request.  All users of your 
>>>>>> application would be allowed to set or unset RPC registrations 
>>>>>> in that case.
>>>>
>>>> I think you are correct.  This is probably due to some combination
>>>> of ignorance and stupidity on my part.  I didn't realize that libtirpc
>>>> was a drop-in replacement for the glibc RPC routines.
>>>>
>>>>> I was under the impression rebuilding the applications was not
>>>>> possible... but maybe I misunderstood... 
>>>>
>>>> Rebuilding should be possible, I need to look into this.
>>>>
>>>>> But in the end, I guess I'm not against having functionality 
>>>>> like this... If it make it easier for people to port legacy
>>>>> applications to Linux, its probably a good thing... 
>>>>
>>>> I think the patch does add more control over rpcbind behavior, but I
>>>> grant that it may be less interesting if nobody is using IP to connect
>>>> from local clients.  Nonetheless, it still adds the ability to have
>>>> separate control over whether to accept remote set/unset calls and
>>>> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
>>>> still relevant even if libtirpc is used.
>>>
>>> Not to put to fine a point on it, but we discourage the use of 
>>> indirect RPC calls.  It's a well-known security hole.  Also, 
>>> allowing anyone to set and unset RPC registrations is also 
>>> insecure, and is discouraged.
>> True... but its been this way for years... and always will be... 
>>
>>> In general we want people to switch to using AF_UNIX for local 
>>> registrations, as that is secure from remote attack, and allows 
>>> rpcbind to assign ownership of the registration so that only the 
>>> user who registered that service may unregister it.
>> If the option of rebuilding is available, yes, people should
>> switch to libtirpc... 
> 
> Andrew makes a good point.  There would be no "switch to libtirpc" 
> if distributions had a single RPC implementation.
> 
> Is there a good reason we still have the glibc RPC implementation?
I would guess for legacy reasons... I guess we could open an
Fedora bz asking to disable the code...

steved.
 
> We've resolved the licensing issue already, so there's nothing 
> stopping any Linux distribution from adding a libtirpc package.
> 
>>
>>>> So I would argue that the patch is still a good thing, but I agree that
>>>> I should relink my code with libtirpc.
>>>
>>> IMO we shouldn't add features that encourage people to configure 
>>> rpcbind insecurely, especially when there are reasonable alternatives.
>> The -i is already a securely hole... So if we are concern about it
>> we should get ride of the -i completely... Or make it a useful 
>> securely hole... ;-)
>>
>> The point of this patch was to make it easier for people 
>> to port legacy applications to Linux... If this indeed 
>> is the case, I think that overrides these (self induced) 
>> security issues... 
> 
> If we go with just the evidence at hand: Andrew says he can rebuild his application.  Thus, so far there is no specific requirement to expand "-i".  IMO we should wait until there is, in the most noble of Linux traditions.
> 

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 10, 2010, at 12:07 PM, Steve Dickson wrote:

> 
> 
> On 12/10/2010 12:01 PM, Chuck Lever wrote:
>> Hi Steve-
>> 
>> On Dec 10, 2010, at 10:55 AM, Steve Dickson wrote:
>> 
>>> On 12/10/2010 10:31 AM, Chuck Lever wrote:
>>>> 
>>>> On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote:
>>>> 
>>>>> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote:
>>>>>> 
>>>>>> 
>>>>>> On 12/09/2010 04:41 PM, Chuck Lever wrote:
>>>>>>> It sounds like your application is trying to use glibc's RPC 
>>>>>>> implementation with rpcbind.  If you build your application with 
>>>>>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind 
>>>>>>> instead of loopback.  The AF_UNIX socket carries some authentication 
>>>>>>> information with the registration request.  All users of your 
>>>>>>> application would be allowed to set or unset RPC registrations 
>>>>>>> in that case.
>>>>> 
>>>>> I think you are correct.  This is probably due to some combination
>>>>> of ignorance and stupidity on my part.  I didn't realize that libtirpc
>>>>> was a drop-in replacement for the glibc RPC routines.
>>>>> 
>>>>>> I was under the impression rebuilding the applications was not
>>>>>> possible... but maybe I misunderstood... 
>>>>> 
>>>>> Rebuilding should be possible, I need to look into this.
>>>>> 
>>>>>> But in the end, I guess I'm not against having functionality 
>>>>>> like this... If it make it easier for people to port legacy
>>>>>> applications to Linux, its probably a good thing... 
>>>>> 
>>>>> I think the patch does add more control over rpcbind behavior, but I
>>>>> grant that it may be less interesting if nobody is using IP to connect
>>>>> from local clients.  Nonetheless, it still adds the ability to have
>>>>> separate control over whether to accept remote set/unset calls and
>>>>> whether to honor indirect/callit calls.  Unless I'm mistaken, this is
>>>>> still relevant even if libtirpc is used.
>>>> 
>>>> Not to put to fine a point on it, but we discourage the use of 
>>>> indirect RPC calls.  It's a well-known security hole.  Also, 
>>>> allowing anyone to set and unset RPC registrations is also 
>>>> insecure, and is discouraged.
>>> True... but its been this way for years... and always will be... 
>>> 
>>>> In general we want people to switch to using AF_UNIX for local 
>>>> registrations, as that is secure from remote attack, and allows 
>>>> rpcbind to assign ownership of the registration so that only the 
>>>> user who registered that service may unregister it.
>>> If the option of rebuilding is available, yes, people should
>>> switch to libtirpc... 
>> 
>> Andrew makes a good point.  There would be no "switch to libtirpc" 
>> if distributions had a single RPC implementation.
>> 
>> Is there a good reason we still have the glibc RPC implementation?
> I would guess for legacy reasons... I guess we could open an
> Fedora bz asking to disable the code...

Thanks, that would be an excellent first step.

> steved.
> 
>> We've resolved the licensing issue already, so there's nothing 
>> stopping any Linux distribution from adding a libtirpc package.
>> 
>>> 
>>>>> So I would argue that the patch is still a good thing, but I agree that
>>>>> I should relink my code with libtirpc.
>>>> 
>>>> IMO we shouldn't add features that encourage people to configure 
>>>> rpcbind insecurely, especially when there are reasonable alternatives.
>>> The -i is already a securely hole... So if we are concern about it
>>> we should get ride of the -i completely... Or make it a useful 
>>> securely hole... ;-)
>>> 
>>> The point of this patch was to make it easier for people 
>>> to port legacy applications to Linux... If this indeed 
>>> is the case, I think that overrides these (self induced) 
>>> security issues... 
>> 
>> If we go with just the evidence at hand: Andrew says he can rebuild his application.  Thus, so far there is no specific requirement to expand "-i".  IMO we should wait until there is, in the most noble of Linux traditions.
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

On Fri, Dec 10, 2010 at 12:01:51PM -0500, Chuck Lever wrote:
> If we go with just the evidence at hand: Andrew says he can rebuild his application.  Thus, so far there is no specific requirement to expand "-i".  IMO we should wait until there is, in the most noble of Linux traditions.
> 

To be fair, this will require porting work on my side.  It is not a completely
trivial recompile, since some of the data structures have changed a little
bit.

I don't know whether removing from glibc is a great idea because of this
aspect.  The new TIRPC code is not 100% compatible (for example, struct XDR has
some differences in the xdr_ops).  I personally think that adding
'__attribute__ (( __deprecated__ ))' to all the function prototypes in
/usr/include/rpc/*.h would be a good first step, and also add a comment to the
header files directing people to port their code to the new tirpc API.

Anyway, that's my 2 cents.

Regards,
Andy

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 10, 2010, at 12:10 PM, Andrew J. Schorr wrote:

> On Fri, Dec 10, 2010 at 12:01:51PM -0500, Chuck Lever wrote:
>> If we go with just the evidence at hand: Andrew says he can rebuild his application.  Thus, so far there is no specific requirement to expand "-i".  IMO we should wait until there is, in the most noble of Linux traditions.
>> 
> 
> To be fair, this will require porting work on my side.  It is not a completely
> trivial recompile, since some of the data structures have changed a little
> bit.

The libtirpc legacy API should be the same as the glibc RPC API.  If you spot any truly non-ABI compatible changes, or have any other related questions, please let us know.  (we should probably cc libtirpc-devel@sourceforge.net).

> I don't know whether removing from glibc is a great idea because of this
> aspect.  The new TIRPC code is not 100% compatible (for example, struct XDR has
> some differences in the xdr_ops).  I personally think that adding
> '__attribute__ (( __deprecated__ ))' to all the function prototypes in
> /usr/include/rpc/*.h would be a good first step, and also add a comment to the
> header files directing people to port their code to the new tirpc API.

A port to the new API shouldn't be necessary.  libtirpc has all of the legacy API available.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

Adding CC libtirpc-devel@sourceforge.net:

On Fri, Dec 10, 2010 at 12:14:47PM -0500, Chuck Lever wrote:
> The libtirpc legacy API should be the same as the glibc RPC API.  If you spot any truly non-ABI compatible changes, or have any other related questions, please let us know.  (we should probably cc libtirpc-devel@sourceforge.net).
> 

I have not inspected closely yet, but did notice that the XDR structure
has changed.  In /usr/include/rpc/xdr.h, there is this:

struct XDR
  {
    enum xdr_op x_op;           /* operation; fast additional param */
    struct xdr_ops
      {
        bool_t (*x_getlong) (XDR *__xdrs, long *__lp);
        /* get a long from underlying stream */
        bool_t (*x_putlong) (XDR *__xdrs, __const long *__lp);
        /* put a long to " */
        bool_t (*x_getbytes) (XDR *__xdrs, caddr_t __addr, u_int __len);
        /* get some bytes from " */
        bool_t (*x_putbytes) (XDR *__xdrs, __const char *__addr, u_int __len);
        /* put some bytes to " */
        u_int (*x_getpostn) (__const XDR *__xdrs);
        /* returns bytes off from beginning */
        bool_t (*x_setpostn) (XDR *__xdrs, u_int __pos);
        /* lets you reposition the stream */
        int32_t *(*x_inline) (XDR *__xdrs, u_int __len);
        /* buf quick ptr to buffered data */
        void (*x_destroy) (XDR *__xdrs);
        /* free privates of this xdr_stream */
        bool_t (*x_getint32) (XDR *__xdrs, int32_t *__ip);
        /* get a int from underlying stream */
        bool_t (*x_putint32) (XDR *__xdrs, __const int32_t *__ip);
        /* put a int to " */
      }
     *x_ops;
    caddr_t x_public;           /* users' data */
    caddr_t x_private;          /* pointer to private data */
    caddr_t x_base;             /* private used for position info */
    u_int x_handy;              /* extra private word */
  };

Whereas the new tirpc/rpc/xdr.h has this:

typedef struct __rpc_xdr {
        enum xdr_op     x_op;           /* operation; fast additional param */
        const struct xdr_ops {
                /* get a long from underlying stream */
                bool_t  (*x_getlong)(struct __rpc_xdr *, long *);
                /* put a long to " */
                bool_t  (*x_putlong)(struct __rpc_xdr *, const long *);
                /* get some bytes from " */
                bool_t  (*x_getbytes)(struct __rpc_xdr *, char *, u_int);
                /* put some bytes to " */
                bool_t  (*x_putbytes)(struct __rpc_xdr *, const char *, u_int);
                /* returns bytes off from beginning */
                u_int   (*x_getpostn)(struct __rpc_xdr *);
                /* lets you reposition the stream */
                bool_t  (*x_setpostn)(struct __rpc_xdr *, u_int);
                /* buf quick ptr to buffered data */
                int32_t *(*x_inline)(struct __rpc_xdr *, u_int);
                /* free privates of this xdr_stream */
                void    (*x_destroy)(struct __rpc_xdr *);
                bool_t  (*x_control)(struct __rpc_xdr *, int, void *);
        } *x_ops;
        char *          x_public;       /* users' data */
        void *          x_private;      /* pointer to private data */
        char *          x_base;         /* private used for position info */
        u_int           x_handy;        /* extra private word */
} XDR;


As you can see, the structure has changed (some methods added and others
removed).  As a result, my code to implement a new XDR type no longer compiles,
and will require porting (which presumably will not be major).

So I claim that tirpc is not fully ABI compatible with the legacy RPC
implementation.

Regards,
Andy

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

On Dec 10, 2010, at 4:57 PM, Andrew J. Schorr wrote:

> Adding CC libtirpc-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org:
> 
> On Fri, Dec 10, 2010 at 12:14:47PM -0500, Chuck Lever wrote:
>> The libtirpc legacy API should be the same as the glibc RPC API.  If you spot any truly non-ABI compatible changes, or have any other related questions, please let us know.  (we should probably cc libtirpc-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org).
>> 
> 
> I have not inspected closely yet, but did notice that the XDR structure
> has changed.  In /usr/include/rpc/xdr.h, there is this:
> 
> struct XDR
>  {
>    enum xdr_op x_op;           /* operation; fast additional param */
>    struct xdr_ops
>      {
>        bool_t (*x_getlong) (XDR *__xdrs, long *__lp);
>        /* get a long from underlying stream */
>        bool_t (*x_putlong) (XDR *__xdrs, __const long *__lp);
>        /* put a long to " */
>        bool_t (*x_getbytes) (XDR *__xdrs, caddr_t __addr, u_int __len);
>        /* get some bytes from " */
>        bool_t (*x_putbytes) (XDR *__xdrs, __const char *__addr, u_int __len);
>        /* put some bytes to " */
>        u_int (*x_getpostn) (__const XDR *__xdrs);
>        /* returns bytes off from beginning */
>        bool_t (*x_setpostn) (XDR *__xdrs, u_int __pos);
>        /* lets you reposition the stream */
>        int32_t *(*x_inline) (XDR *__xdrs, u_int __len);
>        /* buf quick ptr to buffered data */
>        void (*x_destroy) (XDR *__xdrs);
>        /* free privates of this xdr_stream */
>        bool_t (*x_getint32) (XDR *__xdrs, int32_t *__ip);
>        /* get a int from underlying stream */
>        bool_t (*x_putint32) (XDR *__xdrs, __const int32_t *__ip);
>        /* put a int to " */
>      }
>     *x_ops;
>    caddr_t x_public;           /* users' data */
>    caddr_t x_private;          /* pointer to private data */
>    caddr_t x_base;             /* private used for position info */
>    u_int x_handy;              /* extra private word */
>  };
> 
> Whereas the new tirpc/rpc/xdr.h has this:
> 
> typedef struct __rpc_xdr {
>        enum xdr_op     x_op;           /* operation; fast additional param */
>        const struct xdr_ops {
>                /* get a long from underlying stream */
>                bool_t  (*x_getlong)(struct __rpc_xdr *, long *);
>                /* put a long to " */
>                bool_t  (*x_putlong)(struct __rpc_xdr *, const long *);
>                /* get some bytes from " */
>                bool_t  (*x_getbytes)(struct __rpc_xdr *, char *, u_int);
>                /* put some bytes to " */
>                bool_t  (*x_putbytes)(struct __rpc_xdr *, const char *, u_int);
>                /* returns bytes off from beginning */
>                u_int   (*x_getpostn)(struct __rpc_xdr *);
>                /* lets you reposition the stream */
>                bool_t  (*x_setpostn)(struct __rpc_xdr *, u_int);
>                /* buf quick ptr to buffered data */
>                int32_t *(*x_inline)(struct __rpc_xdr *, u_int);
>                /* free privates of this xdr_stream */
>                void    (*x_destroy)(struct __rpc_xdr *);
>                bool_t  (*x_control)(struct __rpc_xdr *, int, void *);
>        } *x_ops;
>        char *          x_public;       /* users' data */
>        void *          x_private;      /* pointer to private data */
>        char *          x_base;         /* private used for position info */
>        u_int           x_handy;        /* extra private word */
> } XDR;
> 
> 
> As you can see, the structure has changed (some methods added and others
> removed).  As a result, my code to implement a new XDR type no longer compiles,
> and will require porting (which presumably will not be major).
> 
> So I claim that tirpc is not fully ABI compatible with the legacy RPC
> implementation.

Thanks for the report.  We are aware of a handful of other minor instances, so it is true that there is not full ABI compatibility.  For most RPC applications of sufficient complexity, the differences are not significant.  At a guess, the use of RPCL and rpcgen to construct your XDR type might be helpful for avoiding this problem.

The XDR struct is not part of the published RPC API, is it?  See Sun doc 816-1435.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Chuck Lever]

Correcting the Cc:, apologies.

On Dec 10, 2010, at 4:57 PM, Andrew J. Schorr wrote:

> Adding CC libtirpc-devel@sourceforge.net:
> 
> On Fri, Dec 10, 2010 at 12:14:47PM -0500, Chuck Lever wrote:
>> The libtirpc legacy API should be the same as the glibc RPC API.  If you spot any truly non-ABI compatible changes, or have any other related questions, please let us know.  (we should probably cc libtirpc-devel@sourceforge.net).
>> 
> 
> I have not inspected closely yet, but did notice that the XDR structure
> has changed.  In /usr/include/rpc/xdr.h, there is this:
> 
> struct XDR
>  {
>    enum xdr_op x_op;           /* operation; fast additional param */
>    struct xdr_ops
>      {
>        bool_t (*x_getlong) (XDR *__xdrs, long *__lp);
>        /* get a long from underlying stream */
>        bool_t (*x_putlong) (XDR *__xdrs, __const long *__lp);
>        /* put a long to " */
>        bool_t (*x_getbytes) (XDR *__xdrs, caddr_t __addr, u_int __len);
>        /* get some bytes from " */
>        bool_t (*x_putbytes) (XDR *__xdrs, __const char *__addr, u_int __len);
>        /* put some bytes to " */
>        u_int (*x_getpostn) (__const XDR *__xdrs);
>        /* returns bytes off from beginning */
>        bool_t (*x_setpostn) (XDR *__xdrs, u_int __pos);
>        /* lets you reposition the stream */
>        int32_t *(*x_inline) (XDR *__xdrs, u_int __len);
>        /* buf quick ptr to buffered data */
>        void (*x_destroy) (XDR *__xdrs);
>        /* free privates of this xdr_stream */
>        bool_t (*x_getint32) (XDR *__xdrs, int32_t *__ip);
>        /* get a int from underlying stream */
>        bool_t (*x_putint32) (XDR *__xdrs, __const int32_t *__ip);
>        /* put a int to " */
>      }
>     *x_ops;
>    caddr_t x_public;           /* users' data */
>    caddr_t x_private;          /* pointer to private data */
>    caddr_t x_base;             /* private used for position info */
>    u_int x_handy;              /* extra private word */
>  };
> 
> Whereas the new tirpc/rpc/xdr.h has this:
> 
> typedef struct __rpc_xdr {
>        enum xdr_op     x_op;           /* operation; fast additional param */
>        const struct xdr_ops {
>                /* get a long from underlying stream */
>                bool_t  (*x_getlong)(struct __rpc_xdr *, long *);
>                /* put a long to " */
>                bool_t  (*x_putlong)(struct __rpc_xdr *, const long *);
>                /* get some bytes from " */
>                bool_t  (*x_getbytes)(struct __rpc_xdr *, char *, u_int);
>                /* put some bytes to " */
>                bool_t  (*x_putbytes)(struct __rpc_xdr *, const char *, u_int);
>                /* returns bytes off from beginning */
>                u_int   (*x_getpostn)(struct __rpc_xdr *);
>                /* lets you reposition the stream */
>                bool_t  (*x_setpostn)(struct __rpc_xdr *, u_int);
>                /* buf quick ptr to buffered data */
>                int32_t *(*x_inline)(struct __rpc_xdr *, u_int);
>                /* free privates of this xdr_stream */
>                void    (*x_destroy)(struct __rpc_xdr *);
>                bool_t  (*x_control)(struct __rpc_xdr *, int, void *);
>        } *x_ops;
>        char *          x_public;       /* users' data */
>        void *          x_private;      /* pointer to private data */
>        char *          x_base;         /* private used for position info */
>        u_int           x_handy;        /* extra private word */
> } XDR;
> 
> 
> As you can see, the structure has changed (some methods added and others
> removed).  As a result, my code to implement a new XDR type no longer compiles,
> and will require porting (which presumably will not be major).
> 
> So I claim that tirpc is not fully ABI compatible with the legacy RPC
> implementation.

Thanks for the report.  We are aware of a handful of other minor instances, so it is true that there is not full ABI compatibility.  For most RPC applications of sufficient complexity, the differences are not significant.  At a guess, the use of RPCL and rpcgen to construct your XDR type might be helpful for avoiding this problem.

The XDR struct is not part of the published RPC API, is it?  See Sun doc 816-1435.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

[Andrew J. Schorr]

On Fri, Dec 10, 2010 at 05:22:43PM -0500, Chuck Lever wrote:
> Thanks for the report.  We are aware of a handful of other minor instances, so it is true that there is not full ABI compatibility.  For most RPC applications of sufficient complexity, the differences are not significant.  At a guess, the use of RPCL and rpcgen to construct your XDR type might be helpful for avoiding this problem.

I'm not expert in rpcgen, but doubt that it's helpful for a low-level library
implementing a new XDR type.  I scanned the man page and don't see any relevant
features.  In any case, I agree that the vast majority of code would not be
mucking around with implementing XDR backends; in my case, I wanted a
scatter/gather memory implementation to avoid some needless copies.

> The XDR struct is not part of the published RPC API, is it?  See Sun doc 816-1435.

I'm sure you are correct.  My point is only that the libtirpc implementation is
not 100% compatible with glibc, so deleting the glibc implementation may cause
trouble for some (very) small subset of applications.  I would still recommend
as a first step flagging the legacy interface as deprecated in the
/usr/include/rpc/*.h header files and directing people to use the new API.

Regards,
Andy