Does mountd/statd really need to listen on a privileged port??

mountd/statd currently bind to privileged ports to listen for requests.

This is really a bad thing to do as there is no range of privilege ports that is guaranteed not to be assigned to some service.

sm-notify probably still needs a privileged port to send out notifications on, but that should be relatively short lived so hopefully isn't as much of a problem.

statd needs a privileged port to pass NOTIFY requests down to the kernel and that is probably the first really good reason I've seen to replace the rpc interface between lockd and statd.

But if get mountd and statd to default to choosing a non-reserved port for listening, that would at least decrease the chance that port 631 will be stolen before cupsd gets to bind it.

But is there some reason that mountd/statd need a priv port that I haven't thought of?

Thanks,
NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I usually set statd to '--port 4047 --outgoing-port 4048' and mountd to '--port 4046'. This more or less mirrors what is apparently the default setup on NetApp filers (except the --outgoing-port bit) and has worked pretty well for me.

Cheers
Trond

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

That surprises me...

The socket that statd binds to '--outgoing-port' is used both for sending SM_NOTIFY requests to peer, and to pass incoming SM_NOTIFY requests to the kernel. And the kernel rejects those incoming SM_NOTIFY requests if they are from non-privileged ports.

So I suspect that configuration will not handle the restart of a peer properly.

Which raises the question of SM_NOTIFY and privileged ports.

Does any statd require incoming SM_NOTIFY to be from a privileged port, and from the machine given in mon_name??

Currently linux statd does not, though statd and sm-notify choose a privilege port for outgoing messages by default.

I am tempted to require a privileged port (so that random people cannot successfully ask my lockd to forget all locks from some innocent client), but that would break configurations like yours (even more than they are broken already) and might not work with non-linux machines if they don't use a priv port...

Thoughts?

For now I have changed statd/mountd/rquotad to listen on a non-priv port by default, and statd/sm-notify choose privileged ports that are not registered in /etc/services when possible.

Thanks,
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

s/privilege// ... you have the same problem regardless of privilege state ... svn/mysql/postgresql/etc... can be just as troublesome for people

redhat has a long standing open bug on the topic with no real workable solution (the one posted requires a lot of overhad as every package needs to "opt-in" with the process)

if that's true, then we could at least rewrite the socket code to bind to ports that do not appear in /etc/services (via getservbyport()) ... that'd allow admins to easily prevent things like mountd/statd from hijacking reserved ports ...

i just wish all the rpc things *asked portmap* for the port so we could put all of this logic in portmap and not duplicate effort across all rpc daemons :(
-mike

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

actually, it can be done regardless of how the socket is obtained ... attached is a function i wrote to address this issue but didnt get around to integrating into packages

what do you think ?
-mike

#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

/* Allocate a privileged port that is not reserved according to
* the /etc/services database. This allows the user to reserve
* mark ports as "taken" by updating that file rather than having
* a ton of packages install a ton of little files that somehow
* magically get accumulated to reserve ports ...
* http://bugs.gentoo.org/77810
*
* We do this recursively so that we dont have to worry about the
* libc rebinding the same privileged port over and over again.
* We keep all the sockets open until we find one we're happy
* with and we keep it.
*/
int bind_unreserved_port(int domain, int type, char *protocol)

{
	int s;
	struct servent *serv;
	struct sockaddr_in saddr;
	socklen_t slen;

	/* allocate a socket */
	s = socket(domain, type, 0);
	if (s < 0)
		return s;

	/* attempt to bind to port */
	if (bindresvport(s, (struct sockaddr_in *) 0) != 0)
		goto err_close;

	/* make sure we only bind to non-reserved ports */
	if (getsockname(s, (struct sockaddr *)&saddr, &slen) != 0)
		goto err_close;

	serv = getservbyport(saddr.sin_port, protocol);
	if (serv != NULL) {
		/* this port is listed in /etc/services, so let's try again */
		int punt_socket = s;
		s = bind_unreserved_port(domain, type, protocol);
		close(punt_socket);
	}

	/* awesome, got ourselves a decent port */
	return s;

err_close:

	close(s);
	return -1;
}

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

There are supposed to be some ranges which are never assigned. According to
http://www.iana.org/assignments/port-numbers

DYNAMIC AND/OR PRIVATE PORTS

The Dynamic and/or Private Ports are those from 49152 through 65535

as long as we choose one of those (and that is what happens if you just let the kernel decide for you) there must be no conflict.

I had thought of that too. I'll probably implement it. Your code (in subsequent email) is a little more complicated than needed. Just repeatedly call bindresvport, closing if you don't like it. The port number tried increments each time.

Thanks,
NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

hmm, true ... that is much simpler to grab random ports in that range :)

is that guaranteed somewhere ? when i first worked on the code snippet, i looked for such info and since i couldnt locate any such "the implementation must increment" requirement, i felt the more complicated recursive approach is better since relying on Linux/glibc behavior is not appropriate ... -mike

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

The glibc shipped with Suse has a file called /etc/bindresvport.blacklist that you can add ports to. I thought something similar had found its way upstream by now, but unfortunately I can't find it.

ALTLinux seems to have this patch too.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

i thought Drepper already weighed in on this issue with a response similar to "not a chance in hell" :)
-mike

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Sorry for the delayed response...

I don't think so... since neither mountd or statd checks to see if the source port is a priv port, its not clear why they should listen on one...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I think portmap let's joe doe replace registrations for non-privileged ports. Joe Doe can't do that if the port is < 1024.

Denial of service is obvious. The bad things you can do by spoofing file handles are probably even more interesting: "You want to mount /diskless/root123? Here, try /home/okir/boobytrapped instead"

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

seems like that sort of security is hopelessly outdated in today's networking world ... if the authentication tuple is {ip,port}, then spoofing would certainly already be the source of DoS attacks on portmap
-mike

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

No, pmap_register/unregister must originate from 127.0.0.1, so this is actually some degree of security.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

What... really?

[[Goes to read portmap source code]]
Yuck! From pmap_check.c:

#define reserved_port(p) (IPPORT_RESERVED/2 < (p) && (p) < IPPORT_RESERVED)

#define unreserved_port(p) (IPPORT_RESERVED <= (p) && (p) != NFS_PORT)

#define legal_port(a,p) \
(reserved_port(ntohs((a)->sin_port)) || unreserved_port(p))

and elsewhere (un)registrations are only allowed if legal_port returns true for the source-address, port-number values.

So Joe Doe can unregister any port >= 1024 other than 2049. How gross!
That fact that 2049 has to be an exception should show that the whole idea is wrong. It should record whether a registration was made with a privilege port and if it was, the unregistration must come from a privilege port too... but no.

I guess I'll put back the code to bind to privileges ports by default. But I'll avoid using ports listed in /etc/services.

Thanks.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

But that doesn't help with lockd, does it?
Lockd registers a non-priv port, and fixing that is not trivial. We really should be fixing portmap.

Portmap appeared to be a 10 year old program that each distro maintains their own copy of...

What would people think if I added it to the nfs-utils release and made some improvements? Would that get into distros in parallel with nfs-utils?

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well, portmap is being used by applications which are completely unrelated to nfs (FAM and NIS come to mind) but who depend on it. Including it into nfs-utils doesn't seem natural to me as you would need to have those pieces depending on 'portmap' to depend on 'nfs-utils' even if they are completely unrelated to NFS.

It would seem more natural to have a new upstream portmap maintainer, if needed, that an inclusion in the NFS project. IMHO

In any case, I don't see that many changes being introduced by distributions. Debian's portmap and Fedora/RedHat's portmap is rather similar (there are slightly differences in some command line switches).

If you forwarded some fixes to portmap to the distribution's BTS I'm pretty sure it would get accpeted.

Regards

Javier

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well, the consensus seems to be that a new 'upstream' would not be a bad thing, but that including it in nfs-utils might not be the best idea.

I can live with that, and would like to nominate myself as the new upstream source for 'portmap'. Does anyone object?

I have created a git repository that can be accessed via:
git://neil.brown.name/portmap
or
http://neil.brown.name/git?p=portmap (for browsing).

It starts with the '5beta' tarball that both SuSE and Debian use (Fedora uses a slightly older version 4 tarball).
It then adds a host of fixes which cover almost everything I can find in the Debian, SuSE, and Fedora packages.
The only conflict was the SuSE and Fedora chose a syslog facility of 'AUTH' while Debian chose 'DAEMON' (the original tarball has 'MAIL'). 'DAEMON' makes most sense to me, so that is in the .git.

There are two patches from Fedora that I have not included.

One uses 'getpwnam("rpc")' to find a uid to 'setuid' to. This could be a problem is NIS is in use and 'rpc' isn't in /etc/passwd - portmap would be need to find the NIS server to check for 'rpc' before portmap could start.
Maybe we should make the uid a compile-time option?

The other uses gethostbyname to allow tcpwrappers to provide host-name based access control. This is similarly a potential ground for deadlocks, and the man page from Debian explicitly says that isn't supported so presumably a Debian maintainer has thought about it.

Maybe we could add a compile-time option to enable this if Fedora really wants it.

Also I have made two enhancements of my own (which is the whole point of doing this).

Firstly, registrations made with a privileged port are flagged as such, and can only be deregistered with a request from a privileged port. That makes it safe for statd/mountd etc to listen on unprivileged ports.

The only down side I can see to this is if the sysadmin uses:
pmap_dump
kill
restart
pmap_set
to restart portmap, all the ports will appear to be registered by a privileged user, so a non-root user who is expecting to be able to unregister a port will not be able to.

Partly to address this, and partly because I think it is a good idea, portmap now keeps a copy of it's mapping table in /var/run/portmap_mapping (even when it chroots elsewhere) and will reload it on restart. So pmap_dump/pmap_set is no longer needed.

After any discussion/resolution on the missing Fedora patches, and maybe some testing/review by others, I would like to make a new release (maybe called 6.0), announce it on freshmeat, and put a tar-ball somewhere. Then nfs-utils-1.1.0 will recommend that portmap-6.0 be a dependency as mountd no longer listens on a privileged port.

Comments/review/suggestions welcome.

Thanks for your time.
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'd rather make it a command line option. Maximum freedom for users to shoot themselves in the foot :-)

I agree that this is probably not a very useful patch. But I think the potential for deadlock is actually rather small. For one, if you're on a NIS client, I'm not sure the local portmapper is involved very much at all. For a NIS lookup that starts with a clean state, you need to get the binding information, which nowadays is just being read from /var/lib/yp/binding or some such. The NIS call itself is being placed to the server, and doesn't involve local portmap either. You could possibly get yourself into trouble if you have a machine acting as a NIS server and client at the same time... but that's really kinky stuff.

That's nice! However, beware you have to patch rpcinfo so that rpcinfo -u does a bindresvport when run as root. And *that* change needs to go into all distros, or you need to get it past Uli "hell will freeze over first" Drepper.

I did this quite a while ago when working at Caldera, and there's one gotcha I remember quite vividly - you need to reliably find out whether you're booting (wipe all registrations), or whether the user is just executing "portmap stop; do_silly_stuff; portmap start". Users will not accept that "portmap restart" preserves registrations while the above sequence of commands doesn't. So you need some init script magic to wipe the file when booting. And once you solved that, probably some smart person will complain that this doesn't work when he starts portmap in initrd :-)

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Hmmm...

I guess. It would be really nice if we could delay doing the hostname lookup until we find a hostname present in hosts.{allow,deny}. That would make it run-time configurable. I don't think we can do that though.

No change needed. The rpc library already does bindresvport when creating a client.

My understanding is that /var/run is cleared early at bood. So the idea was that the choice of path name made all that work automatically.

And portmap in initrd? Just Say No. :-)

Thanks for the comments.
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

No, that's not the way tcp_wrappers works. It needs to do the reverse lookup first.

Ah. I was under the impression the automatic bindresvport call had been removed at some point in time. But looking at the glibc cvs it seems it's still there.

Well, if you want portmap to chroot, then it either has to keep a file descriptor open for its map file (which would be at odds with chrooting, because you do that to completely contain the process); or you would have to put the map file somewhere under your chroot tree and have to take care of cleaning it up on boot in a different way.

People have tried to do that, unfortunately.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Is there any particular reason your staying with portmap instead of moving on to rpcbind? Rpcbind supports portmap functionality as well has IPv6 support and warm starts support (meaning it saves state so services don't have to re-register if the rpcbind is restarted).

Another nice benny is, rpcbind used the libtirpc library which is a stand alone lib... meaning we no longer need to depend on the RPC code in glibc... which I think is HUGE... is basically the main reason (other than IPv6 support) I'm pushing Fedora Core in that direction... Braveheart said it best: FREEDOM [from the glibc code]!!! :-D

I (hastily) created two git trees:
git://git.infradead.org/~steved/libtirpc.git
git://git.infradead.org/~steved/rpcbind.git

I think if you take a look, you'll see that
this code may not be as mature as the portmap
code, but its a much better start... imho..

We ensure the rpc uid/gid is created when we install the rpm, but yes if nis is tried before /etc/passwd this will hang but we've never come across such an occurrence (yet :-\ )

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I want distros to include the functionality I want (non-priv users cannot remove registrations of non-priv ports registered by priv users). Given the two approaches:
- please use newer version of portmap
- please dump portmap and use rpcbind
I suspect the former to be more effective.

I'm not against moving to rpcbind, it is probably a very good idea. But I expect there to be more resistance.
If everyone goes to rpcbind and no-one uses 'my' portmap, that would be fine with me.

Yes, very hasty. Several #temporary# and back~ files :-)

I notice that it has a concept of who 'owns' a registration, but it only works if unix-domain sockets are used for the registration. Adding 'superuser' ownership for localhost/privport registrations is probably a 3 line patch....

So: yes. Full steam ahead on rpcbind. But short-term I think it is a good idea to give portmap a little more life.

I wouldn't expect you to. But another distro that doesn't create the right uid/gid might hit it.
I think I'll add -u/-g flags
I might even include the Redhat code in #ifdef, so if compile with
make RPCUSER=rpc
it will do the getpwnam..

Thanks,
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I have added both compile-time and run-time setting of the uid and gid, and allowed a username to be set at compile time. I have also made it possible to compile in host-name lookups. The man-page auto-adjusts to match the compile options.

make RPCUSER=rpc DAEMON_UID=4 DAEMON_GID=100 USE_DNS=yes

I think it is now should do all that I want, and should be a slot-in replacement for any distro that wants it (providing they choose appropriate Make options).

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

When porting this functionality to rpcbind, I made the setting of the uid a configuration argument (i.e. --with-rpcuser=user) See attached patch... Its basically doing the same thing in a different way...

I guess I've become a fan of letting autoconf (and friends) create the makefiles verses me hacking on them... although working with that autoconf API can drive one to drink (which it has ;-) ) but in the end, I do think it makes things a be more configurable...

steved.

commit c24026e7c2949ede4fc292335df1a08c3f6575fe

Author: Steve Dickson <[email protected]>
Date:   Fri Apr 20 13:10:58 2007 -0400

Allow the uid that rpcbind runs as to be set during compile time with the --with-rpcuser configuration flag. The given uid will only be used if the -s flag is not given on the command.

index 0e2f163..dfe5907 100644
@@ -37,6 +37,12 @@ if test "$warmstarts" = "true" ; then
 		AC_SUBST(statedir)
 	AC_DEFINE_UNQUOTED(RPCBIND_STATEDIR, "$statedir", [This defines the location where the state files will be kept for warm starts])
 fi
+AC_ARG_WITH(rpcuser,
+	[  --with-rpcuser=user uid to use [root]],
+	rpcuser=$withval,
+	rpcuser=root)
+	AC_SUBST(rpcuser)
+AC_DEFINE_UNQUOTED(RPCBIND_USER, "$rpcuser", [This defines the uid to run as])
 
 AC_CHECK_HEADERS([arpa/inet.h fcntl.h netdb.h \
                   netinet/in.h stdlib.h string.h \

index 55bbd8d..2a900d9 100644
@@ -68,6 +68,7 @@
 #include <pwd.h>
 #include <string.h>
 #include <errno.h>
+#include "config.h"
 #include "rpcbind.h"
 
 /*#define RPCBIND_DEBUG*/

@@ -79,6 +80,11 @@ int doabort = 0;	/* When debugging, do an abort on errors */
 
 rpcblist_ptr list_rbl;	/* A list of version 3/4 rpcbind services */
 
+#ifdef RPCBIND_USER
+char *rpcbinduser = RPCBIND_USER;
+#else
+char *rpcbinduser = NULL;
+#endif
 
 /* who to suid to if -s is given */
 #define RUN_AS  "daemon"

@@ -206,15 +212,16 @@ main(int argc, char *argv[])
         		err(1, "fork failed");
 	}
 
-	if (runasdaemon) {
+	if (runasdaemon || rpcbinduser) {
 		struct passwd *p;
+		char *id = runasdaemon ? RUN_AS : rpcbinduser;
 
-		if((p = getpwnam(RUN_AS)) == NULL) {
-			syslog(LOG_ERR, "cannot get uid of daemon: %m");
+		if((p = getpwnam(id)) == NULL) {
+			syslog(LOG_ERR, "cannot get uid of '%s': %m", id);
 			exit(1);
 		}
 		if (setuid(p->pw_uid) == -1) {
-			syslog(LOG_ERR, "setuid to daemon failed: %m");
+			syslog(LOG_ERR, "setuid to '%s' failed: %m", id);
 			exit(1);
 		}
 	}

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Conversely, I find autoconf and friends deeply unsatisfying. Both the configure.in and the generated files are just so .... messy.

Yes: if you have autoconf in place, you approach is very sensible. But I would like to avoid autoconf where possible. Hopefully portmap is simple enough that it will remain possible.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I can't agree with you more...

Makes sense... I'm always a fan of keeping things simple!

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Probably... but the latter will need to happen if/when IPv6 supports is wanted...

Good... and I didn't think you were against anything... I wanted let you know there was an alternative

Yeah... for some reason those temporary files are in the the tar ball... I'll work to get that cleaned up..

I'm not sure I understand.. are you talking about how getowner() is being used?

I agreed... portmapper will be around for a long while...

steved

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Is there someone "maintaining" rpcbind? Should there be? I notice there is an rpcbind at Wietse Venema's site:
ftp://ftp.porcupine.org/pub/security/index.html

Is this rpcbind derived from that?

Should rpcbind and portmap "live" close together so that people looking for one will find the other, and so that compatibility (features, options) can be maximised?

Sort of. I was actually looking in pmapproc_change which seems to have 'getowner' open-coded in it.
Both call __rpc_get_local_uid.
That function (in libritpc) returns -1 ( => "unknown") for a AF_INET connection.
I believe that for AF_INET, it should check sin_addr and sin_port. If addr == 127.0.0.1 and sin_port < 1024, then uid should be set to 0.

It would be nice if the libritpc version of bindrecvport could be configured to avoid some list of ports, whether from /etc/services or from elsewhere.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

BTW, I wouldn't use /etc/services as the blacklist for bindresvport. The range of available privileged ports is rather tight already. If you exclude everything found in /etc/services, you're down to 249 ports in the 512-1024 range (for TCP and UDP, each). This will not please the 10,000 mounts crowd at Prominent CPU Vendor :) I really think you want to go with a separate blacklist file.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Certainly supporting a blacklist file and preferring it to /etc/services would make sense. Using /etc/services in the absence of a blacklist should be safe enough.

I wonder if these is something more substantial that can be done to avoid the problems though.

I'm aware to two problems:
1/ ports that are held open for a long time (e.g. the port a server
listens on, or a port that is opened once and used occasionally for sending messages, such as the port statd uses to talk to lockd). These can conflict with servers which wish to bind to assigned port numbers. We can only address this with a black-list.

2/ tcp sockets that linger in CLOSE_WAIT thus preventing other
sockets from binding to the same address. This prevents privilege ports being used at a high rate.
Using UDP avoid this problem but is not always acceptable. I wonder if we could make more use of SO_REUSEADDR in bindresvport. This would require handling an EADDRINUSE from connect, incase we are connecting to the same host as the last time the port was used, but if it is all in the libritpc library, that might be quite manageable. Doing that should reduce the pressure on privileged ports.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

This is risky - while it allows rapid rebinding to the ports, it also allows old duplicate packets in the network to arrive at the newly rebound port, potentially causing it to reset and/or produce unexpected statuses. I would not recommend this as a design requirement!

Tom.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

OBTW - I assume you mean TIME_WAIT not CLOSE_WAIT...

SO_REUSEADDR can't seize a port used by a socket in CLOSE_WAIT because the kernel is waiting for the local file descriptor to be closed. IOW, this is a different problem, and should be short lived, provided that the process that owns the fd is running.

There are also such problems as FIN_WAIT_2, which are even harder to escape from. Bottom line, better to avoid overloading privileged ports as a protection mechanism here, and instead strengthen the portmap/rpcbind registration as mentioned before.

Tom.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Bull maintains a copy of rpcbind alongside their tirpc code. I think both Wietse's and Bull's rpcbind implementation derive from the TI-RPC code released by Sun some time during the last millenium.

Personally, I'm very wary of the tirpc code. I think it needs a haircut and a thorough security audit before it can go into distributions. I did a very quick comparison of the tirpc code vs glibc, and I think there's a potential buffer overflow if a rogue rpcbind server replies with a string length of 0xffffffff.

The rpcb_clnt.c functions use xdr_wrapstring, which gives a max string size of MAX_UNSIGNED, so a string length of 0xffffffff would be acceptable. The subsequent malloc would allocate a buffer of length 0 however. Depending on how you link your binary, malloc may return NULL in that case (simple segfault), or a very small buffer - and the moment you start copying to that, you will corrupt the heap. This is fixed in glibc, but still exists in tirpc. A security audit may turn up more.

Apart from these concerns, the coding style is abominable - K&R almost everywhere; there's still a bunch of u_long's in the code which makes it non-64bit-clean, and there's crap like

clnt_st = CLNT_CALL(client, (rpcproc_t)RPCBPROC_GETADDR,

                    (xdrproc_t) xdr_rpcb, (char *)(void *)&parms,
                    (xdrproc_t) xdr_wrapstring, (char *)(void *) &ua, *tp);

Those casts aren't just plain ugly, they're utterly useless too, since the pointer arguments to cl_call are void *.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I agree the code is a bit rough at this point... and care should be taken with who and how the code is used at this point, which is the reason only rpcbind is using the library and rpcbind is not running as root... but... I do think correct way to go in the supporting of IPv6 and other well established features.

Yes... there is a ton of wisdom we can pull from the glibc code to make this code better... and since the glibc people are for this movement (i.e. moving away from the glibc RPC code) I'm hoping they will be willing to help us out in this effort...

Yes the coding style a bit challenging.... but again this is something that is definitely fixable over time...

Are there any tools out there that might help with the cleaning up of this code?

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Although not the fastes approach the only long-term viable one would be to update the glibc rpc code for the new TIRPC APIs and IPv6 support. Even if it's unclear whether Uli would actually include it that gives a better start to avoid all kinds of security or useability-related regressions.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well I have a strong hunch that the glibc people do not want anything to do with changing *any* of the RPC code. I know for a fact that they are very sorry the accepted in the first place... so with that type of motivation I really think it would be very painful to sell them on take any patches... at all...

Secondly, having the to debug and fix a small part of the RPC code in glibc, I have experienced how truly difficult it is work with such a large beast... so I pretty confident that breaking out the RPC into a library we can maintain ourselves is a good direction to move...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

That's the impression I got, yes.

Well, even with a separate library it's probably better to start out with the glibc code to bug to bug compatible.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

In theory yes... but unfortunately Transport Independent RPC code is much different than the RPC we have in glibc. The TI-RPC code deals with things like CLTS and COTS and has configuration file that defines how theses CLITS/COTS are handled... notions that are completely foreign to the current RPC code...

Again, I realize this code is very raw, but the only way to bring it up to speed (something I really thing we want to do) is using it and making it available to the community.

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

One thing that bothers me is that the current libtirpc[*] is different from other TI-RPC versions. The current version (as far as I understand) is based on a snapshot from FreeBSD, which is turn is based on Suns TIRPC 2.3. This code is *not* up to date with TI-RPC 2.9 (aka tirpcsrc_99) and certainly not with the latest OpenSolaris version.

Another problem with TI-RPC is that a Windows port seems to be hard. That's one reason why I'm not porting unfs3 to TI-RPC.

Getting Linux distributions to ship (the same) version of TI-RPC is a worthwhile goal, but ideally, we should have an upstream project that covers not only Linux, but also, *BSD, OpenSolaris etc. I know it's not going to be easy, but I think it's worth a try.

[*]: http://sourceforge.net/projects/libtirpc

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Teknikringen 3
583 30 Linköping Phone: +46-13-21 46 00

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

CgpQZXRlciDDhXN0cmFuZCB3cm90ZToKPiBPbmUgdGhpbmcgdGhhdCBib3RoZXJzIG1lIGlzIHRo YXQgdGhlIGN1cnJlbnQgbGlidGlycGNbKl0gaXMgZGlmZmVyZW50IAo+IGZyb20gb3RoZXIgVEkt UlBDIHZlcnNpb25zLiBUaGUgY3VycmVudCB2ZXJzaW9uIChhcyBmYXIgYXMgSSB1bmRlcnN0YW5k KSAKPiBpcyBiYXNlZCBvbiBhIHNuYXBzaG90IGZyb20gRnJlZUJTRCwgd2hpY2ggaXMgdHVybiBp cyBiYXNlZCBvbiBTdW5zIFRJUlBDIAo+IDIuMy4gVGhpcyBjb2RlIGlzICpub3QqIHVwIHRvIGRh dGUgd2l0aCBUSS1SUEMgMi45IChha2EgdGlycGNzcmNfOTkpIGFuZCAKPiBjZXJ0YWlubHkgbm90 IHdpdGggdGhlIGxhdGVzdCBPcGVuU29sYXJpcyB2ZXJzaW9uLgpobW0uLi4gV2VyZSBkb2VzIG9u ZSBnbyB0byBmaW5kIG91dCBob3cgdG8gYmUgY29tZSB0aXJwY3NyY185OQpjb21wbGlhbnQgYW5k IHdoeSBpcyB0aGlzIGltcG9ydGFudD8gRG9lcyB0aGUgVEktUlBDIDIuOQp1c2UgYSBkaWZmZXJl bnQgb3Zlci10aGUtd2lyZSBwcm90b2NvbD8gSSBzdXJlbHkgaG9wZSBub3QuLi4gOi1cCgo+IAo+ IEFub3RoZXIgcHJvYmxlbSB3aXRoIFRJLVJQQyBpcyB0aGF0IGEgV2luZG93cyBwb3J0IHNlZW1z IHRvIGJlIGhhcmQuIAo+IFRoYXQncyBvbmUgcmVhc29uIHdoeSBJJ20gbm90IHBvcnRpbmcgdW5m czMgdG8gVEktUlBDLiAKV293Li4uIEkgZGlkbid0IGV2ZW4ga25vdyBXaW5kb3dzIGhhZCBSUEMg c3VwcG9ydC4uLiBidXQKSSBraW5kYSBkb3VidCB3ZSdsbCBiZSBwb3J0IG5mcy11dGlscyB0byBX aW5kb3dzIGFueXRpbWUKc29vbi4uIDotKQoKPiAKPiBHZXR0aW5nIExpbnV4IGRpc3RyaWJ1dGlv bnMgdG8gc2hpcCAodGhlIHNhbWUpIHZlcnNpb24gb2YgVEktUlBDIGlzIGEgCj4gd29ydGh3aGls ZSBnb2FsLCBidXQgaWRlYWxseSwgd2Ugc2hvdWxkIGhhdmUgYW4gdXBzdHJlYW0gcHJvamVjdCB0 aGF0IAo+IGNvdmVycyBub3Qgb25seSBMaW51eCwgYnV0IGFsc28sICpCU0QsIE9wZW5Tb2xhcmlz IGV0Yy4gSSBrbm93IGl0J3Mgbm90IAo+IGdvaW5nIHRvIGJlIGVhc3ksIGJ1dCBJIHRoaW5rIGl0 J3Mgd29ydGggYSB0cnkuCldlbGwgaWYgd2UgaGF2aW5nIHN1cHBvcnQgdGhhdHMgbmVlZGVkIGFu ZC9vciB3YW50ZWQgaXQgc2hvdWxkIG5vdApiZSB0b28gZGlmZmljdWx0IHRvIGdldCBwZW9wbGUg dG8gbW92ZSBvdmVyLi4uCgpzdGV2ZWQuCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBl bWFpbCBpcyBzcG9uc29yZWQgYnkgREIyIEV4cHJlc3MKRG93bmxvYWQgREIyIEV4cHJlc3MgQyAt IHRoZSBGUkVFIHZlcnNpb24gb2YgREIyIGV4cHJlc3MgYW5kIHRha2UKY29udHJvbCBvZiB5b3Vy IFhNTC4gTm8gbGltaXRzLiBKdXN0IGRhdGEuIENsaWNrIHRvIGdldCBpdCBub3cuCmh0dHA6Ly9z b3VyY2Vmb3JnZS5uZXQvcG93ZXJiYXIvZGIyLwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpORlMgbWFpbGxpc3QgIC0gIE5GU0BsaXN0cy5zb3VyY2Vmb3Jn ZS5uZXQKaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbmZzCg==

C =

The chance that Sun actually changed any of the interfaces from one version of TIRPC to the next is virtually nil. Compatibility is a huge thing to them. Any changes would most likely have been made in a backwards compatible fashion.

And no, there are no differences in the over the wire protocol.

Having such a project would be a good thing. We would need developers for each release platform targeted though. Perhaps it might be sufficient to start with platforms that we are interested in and as people with other platforms become interested, they can port the support and add their own patches to the central source base.

I don't think that I understand why being bug for bug compatible with the current glibc code is interesting. This is a new version of the RPC support and applications will explicitly need to be ported to it. Perhaps we could even pleasantly surprise some folks by addressing some particular pet bug that they might have encountered.

    Thanx...

       ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well, you don't want to re-introduce bugs that have been fixed in glibc ages ago, right? Especially when it comes to security issues and thread safety.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

No, clearly, I wouldn't want to do that. However, I don't believe that that is what is meant by "bug for bug compatible".

It is also a distinct possibility that the folks maintaining the TI-RPC code which is in common use may have fixed a few bugs since the Linux source bases, either the glibc or tirpc versions, were acquired. I think that it would be good to have those, _plus_ any bugs which may already been fixed in the glibc version. Wouldn't you agree?

    Thanx...

       ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Which is why I did this comparison of the code today. In summary, in the common files there's stuff in tirpc that glibc misses, but the other way round there's just more.

I don't say tirpc is bad. What I say is, it's better to handle this the way we deal with changes to the kernel: start with what you have, and which you know works well. Add to it, until you have the functionality you want. On the way, you may find out there's better ways of solving things that you anticipated. If you run into sudden problems, you can bisect.

For instance, I would rather like to see the current functionality extended transparently:

- svc{tcp,udp}_create create an IPv6 socket rather than
an IPv4 socket by default. Try to use rpcbind style registrations, but fall back to portmap if it doesn't exist. This needs some extra magic to handle IPv6 mapped IPv4 addresses in svc_getcaller, but that should almost do it

- clnt{udp,tcp}_create needs some magic to find out
whether to use IPv6 or IPv4. The ability to create an IPv6 socket doesn't mean anything; we probably need a config mechanism somewhere. Else you will end up with an awful lot of timeouts (ask the web browser folks about their IPv6 pains). But it doesn't have to be something complicated like netconf; it's more like an IPv6 on/off switch, and a "prefer IPv4/IPv6" switch.

Good heuristics to decide whether to try IPv6
- ability to open an IPv6 socket
- DNS returns IPv6 addrs for the remote host
- there's an rpcbind on the server host, and it
returns udp6/tcp6 registrations
- if it's a global address, we need an interface
with a global prefix
- if it's a link local prefix, just try it.

- make clnt_create understand udp6/tcp6

This is the stuff we can do today, with little overhead, to bring IPv6 support to the distros without making their choices difficult. All we need is

- rpcbind
- rpcb client in the sunrpc lib
- make bindresvport ipv6 aware
- extended functionality as descrived above

This will not be perfect, but it would be a start. From there, you can proceed by fixing clnt_broadcast to deal with IPv6; you can add netconf if you want, and the whole tirpc API if you wish.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Following this logic, should we add rpcbind functionality to portmap rather than throw it out and start with something less known???

I'd have to read up more on rpcbind before I could have an opinion on that.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'm not sure. The rpcbind code isn't exactly pretty, but neither is portmap.

Anyway, I guess in order to prove my point about the sunrpc library I should cough up some code to prove it can be done. I'll be uploading some patches later tonight or tomorrow.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Before we go too far down the road of ignoring all of the work that the engineers at Sun have been doing on the RPC library, is there a way of getting a newer version of the RPC support to start with? The current stuff is quite old.

    Thanx...

       ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I managed to find a copy of tirpc99 and the code layout looks very different. Get it from http://members.plug.org.au/~raven/tirpc99/.

We would need to review the license as I think there's a reason we see the tirpc 2.3 version everywhere.

Ian

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Okay, here we go. Please have a look at
http://oss.oracle.com/~okir/newrpc/

This makes the client side IPv6 aware, by introducing some concepts and terminology from TIRPC without pulling in that code wholesale. (In fact, the only bits I copied from the TIRPC code base were header files, but that's just because I like to tinker; I guess some things such as the netconfig stuff might as well be used verbatim, at the expense of making some code more complicated.)

It hasn't seen much testing; I just confirmed that it still seems to work with IPv4. The IPv6 side hasn't seen any testing yet.

Please consider this as a proof of concept.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'd be interested in why people want the netconfig stuff. I can't see how it makes any sense out of context on a socket based system.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well, it's a nice if you have a single handle that ties address family, socket type, ipproto and a name (aka netid) together. That's all, at least from my point of view. Representing all that info as strings in a netconfig object is not all that useful

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'm very curious.... why is there such a love affair with the glibc code? Its one of the oldest version running.. it has not been well maintained (basically because it couldn't be)... The code has compatible issues when apps are ported to it (I have bugs to prove that)... so why is there such a reverence for code that can arguably be called a lesser implementation?

As far as moving the glibc into a stand alone library, I not sure how that sense either... I guess the idea is to take the old code and added in a new network stack resulting in pile of code that has zero amount testing... verses going with time tested
code that is known to work but does have couple of issues...

From a risk management point of view, it seems to me the latter is
heads and shoulders above the former... so again, why does it make sense to do this?

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Hi all,

For us Bull, TI-RPC is just a mean to supply IPv6 support for RPC. We always have considered that it is a raw code with bugs and code =

craps, that has not been tested enough.
We just use and supply it to test IPv6 support for NFSv4. And the code =

is stable enough to do tests with NFSv4 and IPv6. However, we are developping some tests to improve its reliability, =

stability, performance, to make it acceptable in a more general context.

In the past, we discussed with glibc people to extend SunRPC library =

with IPv6 features. Uli Drepper clearly refused and explained that he =

did not want to see new bugs entering in RPC glibc library. He seems to =

consider that RPCs should not be in the glibc, and introduction of new =

features must be done in an external library.

That's why we decided to port an external tirpc library from FreeBSD =

(which is based on the same Sun code than Wietse's )

Aur=E9lien

C =

-- =

********************************
Aurelien Charbon
Linux NFSv4 team
Bull SAS
Echirolles - France
http://nfsv4.bullopensource.org/
********************************

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

The over-the-wire protocol should be the same. I'm not sure about the API, but even if it's the same, I'm a bit worried that TI-RPC 2.9 contains bugfixes or features that 2.3 is missing.

tirpcsrc_99 used to be available from sun.com, but it isn't anymore. I have a copy at http://www.cendio.se/~astrand/oncrpc/, though.

Windows has a lot of different RPC mechanism, but Microsoft does not support the ONC RPC API except that with "Services for UNIX". So if you want to port an application that uses ONC RPC, without using SFU, you'll need an external library. Many commercial ones are available. Several free ones are also available, but as far as I understand, none of these are maintained, except http://oncrpc-ms.sourceforge.net/ (which I maintain myself :-).

nfs-utils on Windows doesn't make much sense, but there are other applications that does. unfs3 is one of those. Besides, wouldn't it be nice if developers could use ONC RPC a little bit often, instead of solutions like SOAP ? :-)
(http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
is worth reading.)

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Teknikringen 3
583 30 Linköping Phone: +46-13-21 46 00

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Still, there's a whole load of shared code, and this is where I agree with Christoph that it would be foolish to throw away the work that went into the glibc code. The buffer overflow fix I mentioned is just one such thing - I did a diff of the files common in glibc and tirpc, and here are some of the things I found.

- glibc authunix_create_default works if the process has
more than NGRPS gids. tirpc wil fail

- glibc tries to be more multithread friendly, by using
things like gethostbyname_r instead of gethostbyname. tirpc doesn't.

- it seems that tirpc unconditionally requires rpcbind,
even for applications that still use pmap_set and friends. In the interest of a smooth transition, applications using the old interface should be able to expect the old behavior.

- tirpc does truly bizarre things, eg in clnt_raw.c

	it declares a local variable, and then acquires
	a mutex to check this local variable for NULL:

	       mutex_lock(&clntraw_lock);
	       if (clp == NULL) {
	               mutex_unlock(&clntraw_lock);
	               return (RPC_FAILED);
	       }
	       mutex_unlock(&clntraw_lock);

- tirpc has a mechanism that lets you register
server side auth flavors dynamically; libc doesn't.

- glibc switched to poll(), whereas tirpc still uses
select with all its limitations

- in tirpc, svc.c seems to be thread safe, whereas
glibc isn't.

- tirpc lets the application control the maximum record
size, making DoS attacks just a little harder.

- in tirpc, xdr_mem.c has different ops for aligned vs
unaligned buffers, for what it's worth.

- in tirpc, clnt_sperror uses snprintf to avoid buffer overflows,
but gets it all wrong wrt the return value of snprintf.

- tirpc is K&R all over the place, while glibc is mostly
cleaned up (not everywhere though)

- tirpc bindresvport is IPv6 aware, but has a bug: if the
caller passes a sockaddr with sin_port/sin6_port set, the routine will actually bind to htons(port). the libc bindresvport implementation also has a small optimization in that it will continue searching where the previous call to bindresvport left off, rather than starting all over from 600.

- the authunix code in tirpc assumes sizeof(gid_t)
equals sizeof(int)

- the glibc RPC client side seems to be thread safe, whereas
tirpc seems to be lacking in some areas (see rpc_thread.c)

I stopped reading the code after an hour, but I think this list could be extended quite a bit.

So from my POV the decision between tirpc and glibc rpc isn't that clear-cut. TIRPC clearly needs some work before distros should consider using it.

Well, there's one thing that makes the transition very tricky. I looked into this while I was still with Novell, because we had a request from the Bull folks to include tirpc. If you include tirpc, you either have to remove all RPC code from glibc at the same time, and fix up all applications linking against this code. Downside: no binary compatibility, and the customers who paid a lot of money for some commercial app will hate you if an OS upgrade requires them to buy new licenses.

The other approach is to make sure that you provide *any* RPC related symbol glibc provides, in tirpc as well. Even if it does nothing, and just errors out. Otherwise you may end up with somebody's application linked against tirpc, but it calls some forgotten little function in glibc and falls over. This is tricky too.

This is why I had very strong reservations about including tirpc in SLES.

I'm wondering whether all that hassle is really worth it. There should be a way to IPv6 enable the glibc RPC implementation without having to go to TIRPC. Yes, Solaris requires rpcbind and such in order to do IPv6. But that's not the same as replacing glibc's sunrpc code.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Yepp. One other thing about tirpc is that it pulls in a lot of TLI crap. Given that we never implemented TLI on Linux and never will this seems like a lot of useless baggae.

(Especially as SUN is backing down a lot on TLI aswell)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I really don't have any idea what SUN is or is not doing, and sure it *might* be possible to simply turn IPv6 in the glibc RPC code but its been stated very clearly that will not happen because the glibc people no longer want to support that code... They have and will continue to resit any and all changes...

So all I'm trying to is instead of beating our heads against the glibc wall, I simply trying to go around it with an alternative solution and the libtirpc library seems like it would be a good alternative...

Are there any other alternatives out there???

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Whatever we do, there needs to be some coordination with the glibc folks. If they don't accept any patches to the sunrpc code in their code base, then we need to talk about a way of transitioning that code out of there.

Isn't there a way to frob symbols so that the loader finds them while hiding them from the linker? That would allow us to link apps against a new librpc without risk of pulling in symbols from glibc, and at the same time maintain binary compatibility in glibc runtime. I'm not enough of a toolchain person, but I think stuff like that is done routinely.

With that in place, you can decide whether it's easier to go to libtirpc and pull in any missing pieces from glibc, or whether it's better to start with a copy of the glibc code, put it into git somewhere and evolve it from there. I think the latter approach makes more sense. Gradual transisitons are always preferrable.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Yes.

The only way to hide symbols seems to adding a new version symbol of the same name ontop of it. Which actually might make some sense here by making the new versions stubs while preserving ABI compatiblity for any old binary around. But I suspect third parties would still get very upset about this compile-time breakage.

Another alternative would be to not mess with the symbols in glibc at all but use linker magic to emit a warning that people should use librpc instead, similar to how linking any application using getc against glibc will get you a warning that it's dangerous and should not be used.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'm positive, creating a separate library based on the current glibc RPC code seems like a nice solution to me.

You mean gets()? I like this approach.

Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I have the feeling we're talking past each other here :-)

Even if changes to glibc itself are not going to happen you still can take the glibc rpc code, make changes to it and turn it into a separate library. Given the indicators that Ulrich doesn't want new features in glibcs that seems to be the most useful solution.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Again I can't agree with you more... so lets port over that "wisdom" into libtirpc...

Thanks for spending the time!!! I'll make sure each an every one of these observations turning into a bug report...

Removing the RPC code from glibc is not an option. The glibc people have made this very clear... So I see the libtirpc library as an alternative to people that want RPC over IPv6 support... and Yes they will have to recompile to take advantage of this support... but I really don't think that will be that big of a deal..

Again... libtirpc is not replacing the glibc code. People will have to explicitly link with the tirpc... Will there be porting issues... yes... aren't there always?

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Fixed in git://git.infradead.org/~steved/libtirpc.git
(commit 30431c6d846eab1bc6b7a3a91a7894f3acf2680f)

But there was code that check for nodesize being zero so it not completely clear that this buffer overflow was a real threat...

Note the following comment in the glibc code:
/* This braindamaged Sun code forces us here to truncate the
list of groups to NGRPS members since the code in authuxprot.c transforms a fixed array. Grrr. */
So the glibc can indeed allocate memory a ton of gids but then only sends NGRPS of them... which is a complete waste of memory and time... imho..

Well since gethostbyname_r() is a GNU extension it understandable why its not in the BSD based code... Also in tirpc, gethostbyname() routine is *not* used in the highly used clnt_create() call as its is in glibc . In tirpc the routine getaddrinfo() is used to resolve host names in clnt_create() and I don't think there is a thread safe version of that...

Also the only two place gethostbyname() is used in tirpc is in getrpcport() and in the a few calls down from authdes_refresh().

Now there are calls to mutex_lock/unlock so in the end there multithread support... at least in that part of the code...

I not understanding your point... all the pmap_xxx routine are supported, taking the same arguments and return same value. Internally they definitely do things differently, which should not be a problem...so where are you seeing the potential transition problems?

Look again... clp is pointing to global data... so locks are needed...

educate me... why is using poll() better than select()?

hmm... how is:

     i = snprintf(str, len, "; errno = %s", strerror(e.re_errno));
     if (i > 0) {
         str += i;
         len -= i;
     }

wrong? looks reasonable to me... what am I missing?

I'm not sure why "K&R all over the place" is bad but the tirprc code is much better documented and much less hacker... Meaning, in the glibc code, fixes did not follow the original style... which make the fix stand out... this is not the case with the tirpc code...

I must be missing something... in the AF_INET6: the port is set to sin6->sin6_port; which will be the first port that is tried... right? and that is bad?

I ironic you bring this up.. this is the result of a bug I found and with this experience I learned how difficult it truly is to get things fixed in glibc.. anyways this is fixed with in my git tree with:
commit c254b435007ebd4ed471737198975d5ccf4e7949

this is true... are there any modern day machine architecture where sizeof(gid_t) == sizeof(short)?

I think *seems* is the key word here... since I can not find any functions that make use of these routines but there is a lot of glibc black magic in that file so maybe indirectly they are...

Please catch your breath... and continue on! :-)

Again I want to thank Olaf for taking the time which caused me to take the time to take close look.... and I'm glad I did... I actually feel tirpc (least the library code) is much better shape that that I thought it was...

Now I did not spend the time just to be argumentative with Olaf... Hell... I hope he keeps poking holes... is the best thing for the code... but I did spend the time because I've never been that impressed with the RPC in glibc in the first place... So I could not image any other implementation to be as bad as I perceived the glibc implementation is and it turns out I was right... the tirpc is time tested, does support IPv6 and is well documented... among other thing... Plus... we have no choice... the glibc people will not change anything... and with Uli... nothing means nothing!

So in the end I truly do think porting rpc service (like nfs-utils, nis, etc) is the right thing to do...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

We don't touch that global data here--since we don't deference clp in that fragment, what it points to shouldn't matter.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

No. If you don't do this, you will not get *any* gids. getgroups simply fails if the array you give it is too short. And tirpc deals with that rather ungracefully by calling abort(), of all things.

getaddrinfo is thread-safe, so that is fine.

Ah, okay.

It means you cannot run a binary linked against tirpc on a host that runs portmap but no rpcbind. E.g. pmap_set will simply fail if it can't connect to rpcbind via AF_LOCAL. I think any replacement for libc's sunrpc code should continue to work in a portmap environment.

Yes, clp is *pointing* at global data, so the data it points at may change. But this pointer itself is a variable on your local stack which is not even visible to any other thread; so it can't change.

I assume this was once meant to protect access to the clntraw_private pointer, which is a global variable and could do with some mutex protection, and I guess at some point the code looked like this:

	mutex_lock()
	clp = clntraw_private;
	if (clp == NULL) {
		unlock and fail
	}

and some misguided soul probably moved the
pointer assignment out of the protected region
so that the code now looks the way it does.
This needs fixing.

fd_set has a limit on the max file descriptor it can accomodate (1024 I think). poll does not. So if you use that code in apps that have files with descriptors > 1024 you will start clobbering heap or stack memory.

Under the hood, they're all the same - glibc's select will call sys_poll.

snprintf returns the number of characters it *would* have printed if the buffer size had been sufficient. It does not return the number of characters actually printed, which is what this code seems to assume. So if the buffer is too small, you end up with str pointing beyond the end of the buffer, and len a huge unsigned value. That is decidedly not what you want :-)

I agree it's a matter of taste. Like wearing bell bottom jeans and pink shirts :-)

It uses htons alright, but it forgot the ntohs

        switch (af) {
        case AF_INET:
                sin = (struct sockaddr_in *)sa;
                salen = sizeof(struct sockaddr_in);
                port = sin->sin_port; /* <--- needs ntohs */
...
		*portp = htons(port++);

Not as far as I know, but that's beside the point I think. This kind of assumption is always bad.

Two more things:

- tirpc does a getenv("NETNAME") which should probably be
secure_getenv().

- in libc, clntudp_call uses the IP_RECVERR feature of the
Linux kernel, so it gets notified of ICMP errors (like port_unreach). The TIRPC code does not, so the application will never see any error and has to wait for a timeout instead.

No offense taken. I should have probably explained my points better than I did

That's where we disagree :-) I think ripping out the glibc code and replacing it will cause a lot of maintenance for the distros.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

It is a distinct possibility that calling abort() is the wrong thing, but so is sending out a message with only part of the gid list. The request can fail due to authentication problems, the user looks and see that he is indeed in the right group(s), and then can't figure out why things didn't work right.

There isn't a clear cut right answer, but the described behavior is at least definitive. There were a _lot_ of discussions inside of Sun, comp.protocols.nfs, and at Connectathons regarding this issue, without clear resolutions that were better than the current behavior.

The TI-RPC code is definitely thread-safe and many portions are also MT-hot. Many of the Solaris RPC based daemons are multi-threaded, like mountd, for example.

This version of the library may or may not be MT-safe, but newer versions are definitely safe. Perhaps the Bull people could tell us how old the library is?

This sounds like a good goal to add to the list of work to do.

It seems to me that you are still missing the point of the lock.

The lock is not being used to protect the assignment of the address of clnt_raw_private to clp, it is being used to ensure that clp is not being used before clnt_raw_private is completely initialized.

The lock is also used to ensure that multiple copies of clnt_raw_private are not allocated.

Arguably, this could have been implemented using a different locking strategy, one which recovered from discovered races, instead of preventing them upfront, but it works and is correct.

Here is a place where a newer version of the TI-RPC library would help.

Yup, that was a bug, and has already been fixed in a newer version of the library.

I think that a short bit of work would convert the argument lists from K&R style to ANSI, so that shouldn't be a factor.

We could also take a shot at addressing the multitude of types which are used and update them to the current thinking.

This seems like another bug that is already fixed in newer versions of TI-RPC.

This seems like a porting issue to me. Thank you for pointing it out so that it can get addressed.

I am curious what basis that you are using for this? Why will this cause either more or less maintenance for distros?

It seems to me that this would give us some RPC code, which we could support, which was newer than the current glibc code, and would have more people working on and supporting it. That all seems like goodness to me. The current situation is that we can't maintain the RPC code at all, which is not goodness at all.

    Thanx...

       ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

The README file claims it's a Sun codedrop from 1993 (!)

It's the same reason why we tell people to send us incremental kernel patches. Replacing a codebase completely is a not calculateable risk. It might work out just fine, but usually it doesn't because something silently breaks. Updating the existing codebases with small bugfixes or new features means you have to think about and justify every little understandable change and there's a much higher chance that it won't cause problems. In the end some of them will cause problems anyway, but at least you can easily track the problem down to a single change now.

I don't think the problem is that we can't maintain it, but rather that no one stepped up to maintain it so far.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Woof! There may have been a few bug fixes made since then... :-)

Yes, I agree with all that.

However, we are also looking at making fairly major changes to the support already. I think that the situation will be more complex than we would ideally like, no matter what we do. The IPv6 support is not trivial stuff and will most likely have an impact on the applications that use RPC no matter what we do. There are other things that we can and perhaps should do as well to increase the usefulness of the support. I suspect that there are things that we could do to reduce the number of UDP and TCP ports being used, for example.

I had the impression that SteveD had stepped up. Or am I speaking out of turn for him? :-)

ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

All this would hopefully be optional so we can at least switch back to the old behaviour for debugging purposed.

Anyway, back to the topic of codebases. I'm not sure a 1993 codedrop
that went through a few hands since is a good start. I suspect the
best that could be done (although it involves a lot of the work) is the following:

(1) split out the glibc rpc code into a library of it's own
(2) reformat the latest sun tirpc code drop and the ex-glibc code the same way so it can actually be properly diffed
(3) compare it and port important fixes and possibly features over from that codebase

Now there's some interesting differences between the two, not just in the bug/feature categories Olaf already wrote a lot of notes. For example I assume the latest Sun code still uses their own threading package with the thr_ prefix functions that are quite different from pthreads in many ways, while the glibc code currently uses glibc's internal locking macros so both would need a conversion to the proper pthreads interfaces first, etc.

(and the 2.3-based, ex-freebsd bull code uses a lot of ugly macros
to convert freebsd internalish locking and other libc bits back to posix, that's not exactly maintainable either)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Since the libtirpc is already in FC6 (extras) and will be in FC7, I have every intention on help the Bull people in maintaining this code...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Are we talking of the same piece of code? Can you explain to me how the following, which is a copy of Bull's TIRPC library, ensures this?

clntraw_create:

        struct clntraw_private *clp = clntraw_private;

[...]

        mutex_lock(&clntraw_lock);
        if (clp == NULL) {
                clp = (struct clntraw_private *)calloc(1, sizeof (*clp));
                if (clp == NULL) {
                        mutex_unlock(&clntraw_lock);
                        return NULL;
                }
[...]
                clntraw_private = clp;
        }

Assume 2 threads enter clntraw_create simultaneously, and clntraw_private is NULL.
Both execute clp = clntraw_private, and both see a value of NULL. Thread A grabs the mutex, thread B blocks.

Thread A finds clp == NULL, allocates memory, puts the pointer into clntraw_private, does clever stuff and releases the mutex.

Thread B wakes up, acquires the mutex. It checks
clp, which is still NULL, and allocates another
private object.

I really do think I understand the code, and there is a problem. The mutex protects the clntraw_private pointer, so the only safe thing to do is access that variable while holding the lock, *not* before.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

You are right, the code snippet above is obviously incorrect.

My apologies, I was looking at two different pieces of code and commented about one, in response to comments about the other. I also hadn't realized that you were talking about clntraw_create because there are several other instances of pretty much the same construct in other places in the same file.

The newer versions of the TI-RPC support have this bug fixed. Plus, they use the global variable, clnt_raw_private, instead of clntraw_private. (That's why I changed the name in my response...)

ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

At least authunix_create should return NULL, not make the application die with SIGABRT.

Yes, authentication may fail, but it's better to try and fail than give up without trying.

[...]

[...]

[...]

[...]

[...]

You see why I'm arguing against just replacing working code with something else, without understanding the ramifications?

Seems like at least it's time for a mor recent tirpc version.

I admit this is not founded on anything quantifiable. Let's say based on experience, if you replace 22,000 lines of code used heavily by almost everyone, there's going to be considerable churn. If you just rip out the getgroups change in glibc and go back to the abort() behavior we discsussed above, I'd bet there will be level3 support calls at $your_favorite_linux_vendor that force you to put that code back in.

I'm all for forking the sunrpc code. I'm just not convinced that it is a good idea to replace code that is arguably stable with something else which may have been tested on Solaris but not on Linux.

Olaf

Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Here, we are probably just going to have to agree to disagree, since I don't agree and I don't think that this is the place to hold that discussion, again. :-)

Well, I don't quite think that it is that black and white. Sometimes, changes like this one will prove to be, can affect functionality.

Yes, definitely. :-)

Maybe. I also wouldn't be surprised if no one noticed for quite some time too.

I am one of those who believe that there finally comes a time to cut the past loose and move forward with a whole new code base. This sort of decision must be made carefully, but continuing to hack and kludge on the same old code, just for the sake of the perception that doing so won't impact existing users, always just ends up being false and those users get impacted.

Change is not something to be afraid of. It is healthy and as long as we make intelligent decisions, based on as much information as we can get, we will be fine and our users will be pleased with us.

ps

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

The following commits are on:
git://git.infradead.org/~steved/libtirpc.git

I'm still working on this... but I am wondering why this would be important.. why look back?

commit 419d35db75ab8bd8f79c424f529a6c2f7c4f5fa7

Author: Steve Dickson <[email protected]>
Date:   Fri May 4 09:27:00 2007 -0400

Fixed mutex locking problem in clnt_raw.c. One should grab the clntraw_lock before accessing at clntraw_private, not after.

still looking into this... I need to port to some applications to test this out...

commit a3a3a4e5157932c254200e3b31a78739f5878071

Author: Steve Dickson <[email protected]>
Date:   Fri May 4 11:27:43 2007 -0400

Ignore the return value of snprintf() and use strlen() instead to bump the pointer in clnt_sperror()

Also removed calls to assert(), not needed.

commit 83cb8b02f87fe6fd7bbd903e4825f7cb38e59ec4

Author: Steve Dickson <[email protected]>
Date:   Fri May 4 12:19:27 2007 -0400

A couple ntohs() were needed in bindresvport_sa()

Cound not find where secure_getenv() is defined and it didn't seem to be used in any of the glibc code, but getenv() is...

commit 40ab0c28e995786d5844bd490a31b788ecabf546

Author: Steve Dickson <[email protected]>
Date:   Fri May 4 14:26:56 2007 -0400

Added IP_RECVERR processing with to clnt_dg_call() so application will see errors instead of timing out

Don't worry... that glibc code is going anywhere... but when IPv6 supported is need, I'm hopeful the Linux version of libtirpc will be an option...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Well the I got the current code from Bull:
http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php

As far as maintaining it.. since I have vested interested in see this code work (being it now in FC7), I will be playing a active roll in the maintenance, but Bull should probably be seen as the upstream for this code..

No clue... Added Tony to the cc list to see if he knows... but I must say it certainly has the look and feel of the current rpcbind code...

Ah... I see your point...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I agree...

Well with Fedora Core 7, the pormapper has been replaced with Bull's rpcbind which will help in the migration to to IPv6 (among other things like warms starts).

Pormap/rpcbind is an RPC thing... not an NFS thing... Meaning there are other service (i.e. NIS) that needed it... so I really don't think it makes sense to include Pormap/rpcbind in nfs-utils...

But... that does not mean an "upstream version" of rpcbind can be maintained by a single entity that everyone (including the distros) can pull from... Something I could (and would) support...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

And it that upstream version could still live in the nfs-utils tree, couldn't it? Or it annoying to build multiple binary packages from one upstream tree for some reason?

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Its not so much the annoyance... its the fact that other services like NIS also depend on portmap/rpcbind. Why should we require an AFS shop to install nfs-utils just so they can run NIS?

I just think it makes sense to keep them separate...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Right. I mean: can't you build separate portmap and nfs-utils rpms from the same nfs-utils source, and then make AFS depend only on the portmap package? I thought it was pretty common to do that sort of thing.

But maybe there's no particular advantage to having the two together anyway.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Talking with people that know more about rpms that I ever want to know ;-) Yes... it is possible to create multiple rpms, with different names, from one source tree and it is done, but it does cause confusion... so its not clear how common it is...

I really don't see any... I think it would become for a headache than its worth...

steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I'd prefer to have them as separate upstream packages. However, it won't really be much of a problem for debian as I'm the maintainer of portmap and nfs-utils.

The source package will generate a number of binary packages (including the portmap binary package) and other binary packages will depend on the portmap binary package as it happens now.

One problem that I see is that users will have to deal with a much bigger source package to create patches for portmap.

Another problem is that to build portmapt, users only interested on portmap and not interested on NFS will have to build-depend on all the nfs-utils build-dependecies.

Anyway, I like Neil's proposal. :)

Best Regards,

Aníbal Monsalve Salazar

http://v7w.com/anibal

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs