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

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

[Neil Brown]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Trond Myklebust]

On Fri, 2007-04-13 at 08:05 +1000, Neil Brown wrote:
> 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?

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Neil Brown]

On Thursday April 12, trond.myklebust@fys.uio.no wrote:
> 
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]

On Thursday 12 April 2007, Neil Brown wrote:
> 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.

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)

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

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 511 bytes --]

On Thursday 12 April 2007, Mike Frysinger wrote:
> 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 ...

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: bindresport.c --]
[-- Type: text/x-csrc, Size: 1457 bytes --]

#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;
}

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Neil Brown]

On Thursday April 12, vapier@gentoo.org wrote:
> On Thursday 12 April 2007, Neil Brown wrote:
> > 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.
> 
> s/privilege// ... you have the same problem regardless of privilege state ... 
> svn/mysql/postgresql/etc... can be just as troublesome for people

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.

> 
> 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 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1081 bytes --]

On Thursday 12 April 2007, Neil Brown wrote:
> 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.

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

> 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.

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Olaf Kirch]

On Friday 13 April 2007 03:39, Neil Brown wrote:
> > 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 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

On Tuesday 17 April 2007, Olaf Kirch wrote:
> On Friday 13 April 2007 03:39, Neil Brown wrote:
> > > 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 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.
>
> 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.

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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Steve Dickson]

Sorry for the delayed response...

Neil Brown wrote:

> 
> But is there some reason that mountd/statd need a priv port that I
> haven't thought of?
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Olaf Kirch]

On Monday 16 April 2007 20:13, Steve Dickson wrote:
> > But is there some reason that mountd/statd need a priv port that I
> > haven't thought of?
> 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...

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 931 bytes --]

On Tuesday 17 April 2007, Olaf Kirch wrote:
> On Monday 16 April 2007 20:13, Steve Dickson wrote:
> > > But is there some reason that mountd/statd need a priv port that I
> > > haven't thought of?
> >
> > 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...
>
> 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"

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

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Olaf Kirch]

On Tuesday 17 April 2007 13:21, Mike Frysinger wrote:
> 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

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Neil Brown]

On Tuesday April 17, olaf.kirch@oracle.com wrote:
> On Monday 16 April 2007 20:13, Steve Dickson wrote:
> > > But is there some reason that mountd/statd need a priv port that I
> > > haven't thought of?
> > 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...
> 
> I think portmap let's joe doe replace registrations for non-privileged
> ports. Joe Doe can't do that if the port is < 1024.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Neil Brown]

On Wednesday April 18, neilb@suse.de wrote:
> On Tuesday April 17, olaf.kirch@oracle.com wrote:
> > 
> > I think portmap let's joe doe replace registrations for non-privileged
> > ports. Joe Doe can't do that if the port is < 1024.
> 
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Javier Fernández-Sanguino Peña]

[-- Attachment #1.1: Type: text/plain, Size: 987 bytes --]

On Thu, Apr 19, 2007 at 10:46:49AM +1000, Neil Brown wrote:
> 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?

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 20 April 2007 05:04, Neil Brown wrote:
> 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?

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

> 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.

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.

> 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.

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.

> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Friday April 20, olaf.kirch@oracle.com wrote:
> On Friday 20 April 2007 05:04, Neil Brown wrote:
> > 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?
> 
> I'd rather make it a command line option. Maximum freedom for users
> to shoot themselves in the foot :-)

Hmmm...

> 
> > 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.
> 
> 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.

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.

> 
> > 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.
> 
> 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.

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

> 
> > 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.
> 
> 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 :-)

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 20 April 2007 10:02, Neil Brown wrote:
> 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, that's not the way tcp_wrappers works. It needs to do the
reverse lookup first.

> > 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.
> 
> No change needed.  The rpc library already does bindresvport when
> creating a client.

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.

> 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.

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.

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

People have tried to do that, unfortunately.

Olaf
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Neil Brown wrote:
> 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).
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..


> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Friday April 20, SteveD@redhat.com wrote:
> Is there any particular reason your staying with portmap
> instead of moving on to rpcbind? 

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.

> 
> 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..

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.

> 
> 
> > 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.
> 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 :-\ )

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Monday April 23, neilb@suse.de wrote:
> 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..

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

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



Neil Brown wrote:
> On Monday April 23, neilb@suse.de wrote:
>> 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..
> 
> 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).
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.

[-- Attachment #2: uid.patch --]
[-- Type: text/x-patch, Size: 2183 bytes --]

commit c24026e7c2949ede4fc292335df1a08c3f6575fe
Author: Steve Dickson <steved@redhat.com>
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.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

diff --git a/configure.in b/configure.in
index 0e2f163..dfe5907 100644
--- a/configure.in
+++ b/configure.in
@@ -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 \
diff --git a/src/rpcbind.c b/src/rpcbind.c
index 55bbd8d..2a900d9 100644
--- a/src/rpcbind.c
+++ b/src/rpcbind.c
@@ -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);
 		}
 	}

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Monday April 23, SteveD@redhat.com wrote:
> > 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).
> 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...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Neil Brown wrote:
>>
>> 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...
> 
> Conversely, I find autoconf and friends deeply unsatisfying.  Both the
> configure.in and the generated files are just so .... messy.
I can't agree with you more...

> 
> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Neil Brown wrote:
> On Friday April 20, SteveD@redhat.com wrote:
>> Is there any particular reason your staying with portmap
>> instead of moving on to rpcbind? 
> 
> 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.
Probably... but the latter will need to happen if/when
IPv6 supports is wanted...

> 
> 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.
Good... and I didn't think you were against anything... I wanted
let you know there was an alternative

> 
>> 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..
> 
> Yes, very hasty.  Several #temporary# and back~ files :-)
Yeah... for some reason those temporary files are in the
the tar ball... I'll work to get that cleaned up..

> 
> 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....
I'm not sure I understand.. are you talking about how getowner()
is being used?

> 
> 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 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Monday April 23, SteveD@redhat.com wrote:
> > 
> >> 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..
> > 
> > Yes, very hasty.  Several #temporary# and back~ files :-)
> Yeah... for some reason those temporary files are in the
> the tar ball... I'll work to get that cleaned up..

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?

> 
> > 
> > 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....
> I'm not sure I understand.. are you talking about how getowner()
> is being used?

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Tuesday 24 April 2007 01:09, Neil Brown wrote:
> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Tuesday April 24, olaf.kirch@oracle.com wrote:
> On Tuesday 24 April 2007 01:09, Neil Brown wrote:
> > 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.
> 
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Talpey, Thomas]

At 03:24 AM 4/24/2007, Neil Brown wrote:
> 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 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Talpey, Thomas]

At 11:15 AM 4/24/2007, Talpey, Thomas wrote:
>At 03:24 AM 4/24/2007, Neil Brown wrote:
>> 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 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!

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Tuesday 24 April 2007 01:09, Neil Brown wrote:
> 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?

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Olaf Kirch wrote:
> On Tuesday 24 April 2007 01:09, Neil Brown wrote:
>> 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?
> 
> 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 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.


> 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.
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...

> 
> 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 *.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Tue, Apr 24, 2007 at 09:08:38AM +0200, Olaf Kirch wrote:
> On Tuesday 24 April 2007 01:09, Neil Brown wrote:
> > 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?
> 
> 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 *.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Christoph Hellwig wrote:
> 
> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Tue, Apr 24, 2007 at 01:04:57PM -0400, Steve Dickson wrote:
> >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.
> Well I have a strong hunch that the glibc people do not want anything
> to do with changing *any* of the RPC code.

That's the impression I got, yes.

> 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...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Christoph Hellwig wrote:
>> 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...
> 
> Well, even with a separate library it's probably better to
> start out with the glibc code to bug to bug compatible.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1637 bytes --]

On Tue, 24 Apr 2007, Steve Dickson wrote:

> > Well, even with a separate library it's probably better to
> > start out with the glibc code to bug to bug compatible.
> 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.

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

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

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==

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Steve Dickson wrote:
> Peter =C5strand wrote:
>   =

>> 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 TIRP=
C =

>> 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.
>>     =

> hmm... Were does one go to find out how to be come tirpcsrc_99
> compliant and why is this important? Does the TI-RPC 2.9
> use a different over-the-wire protocol? I surely hope not... :-\
>
>   =


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.

>> 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.
>>     =

> Well if we having support thats needed and/or wanted it should not
> be too difficult to get people to move over...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Tuesday 24 April 2007 22:36, Peter Staubach wrote:
> 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

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Olaf Kirch wrote:
> On Tuesday 24 April 2007 22:36, Peter Staubach wrote:
>   
>> 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
>>     
>
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Wednesday 25 April 2007 17:44, you wrote:
> 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?

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Neil Brown]

On Wednesday April 25, okir@lst.de wrote:
> 
> 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.
> 

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Thursday 26 April 2007 08:32, Neil Brown wrote:
> Following this logic, should we add rpcbind functionality to portmap
> rather than throw it out and start with something less known???

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Olaf Kirch wrote:
> On Thursday 26 April 2007 08:32, Neil Brown wrote:
>   
>> Following this logic, should we add rpcbind functionality to portmap
>> rather than throw it out and start with something less known???
>>     
>
> 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.
>   

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Ian Kent]

On Thu, 2007-04-26 at 09:03 -0400, Peter Staubach wrote:
> Olaf Kirch wrote:
> > On Thursday 26 April 2007 08:32, Neil Brown wrote:
> >   
> >> Following this logic, should we add rpcbind functionality to portmap
> >> rather than throw it out and start with something less known???
> >>     
> >
> > 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.
> >   
> 
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Thursday 26 April 2007 10:59, Olaf Kirch wrote:
> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Fri, Apr 27, 2007 at 05:07:28PM +0200, Olaf Kirch wrote:
> (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.)

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 27 April 2007 17:18, Christoph Hellwig wrote:
> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Olaf Kirch wrote:
> 
> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Aurélien Charbon]

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



Peter Staubach wrote:

>Steve Dickson wrote:
>  =

>
>>Peter =C5strand wrote:
>>  =

>>    =

>>
>>>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 TIRP=
C =

>>>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.
>>>    =

>>>      =

>>>
>>hmm... Were does one go to find out how to be come tirpcsrc_99
>>compliant and why is this important? Does the TI-RPC 2.9
>>use a different over-the-wire protocol? I surely hope not... :-\
>>
>>  =

>>    =

>>
>
>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.
>
>  =

>
>>>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.
>>>    =

>>>      =

>>>
>>Well if we having support thats needed and/or wanted it should not
>>be too difficult to get people to move over...
>>    =

>>
>
>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  -  NFS@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/nfs
>
>  =

>


-- =


********************************
       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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2188 bytes --]

On Tue, 24 Apr 2007, Steve Dickson wrote:

> Peter Åstrand wrote:
> > 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.
> hmm... Were does one go to find out how to be come tirpcsrc_99
> compliant and why is this important? Does the TI-RPC 2.9
> use a different over-the-wire protocol? I surely hope not... :-\

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. 


> > 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. 
> Wow... I didn't even know Windows had RPC support... but
> I kinda doubt we'll be port nfs-utils to Windows anytime
> soon.. :-)

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

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Tuesday 24 April 2007 19:52, Steve Dickson wrote:
> In theory yes...  but unfortunately Transport Independent
> RPC code is much different than the RPC we have in glibc.

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.

> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Wed, Apr 25, 2007 at 10:56:01AM +0200, Olaf Kirch wrote:
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Christoph Hellwig wrote:
> On Wed, Apr 25, 2007 at 10:56:01AM +0200, Olaf Kirch wrote:
>> 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.
> 
> 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)
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Wednesday 25 April 2007 15:22, Steve Dickson wrote:
> Are there any other alternatives out there???

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Wed, Apr 25, 2007 at 04:10:37PM +0200, Olaf Kirch wrote:
> 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.

Yes.

> Isn't there a way to frob symbols so that the loader finds them
> while hiding them from the linker?

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 980 bytes --]

On Wed, 25 Apr 2007, Christoph Hellwig wrote:

> On Wed, Apr 25, 2007 at 04:10:37PM +0200, Olaf Kirch wrote:
> > 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.
> 
> Yes.

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


> 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.

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

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Wed, Apr 25, 2007 at 09:22:06AM -0400, Steve Dickson wrote:
> 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...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Olaf Kirch wrote:
> On Tuesday 24 April 2007 19:52, Steve Dickson wrote:
>> In theory yes...  but unfortunately Transport Independent
>> RPC code is much different than the RPC we have in glibc.
> 
> 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. 
Again I can't agree with you more... so lets port over that
"wisdom" into libtirpc...


> I stopped reading the code after an hour, but I think this list could
> be extended quite a bit.
Thanks for spending the time!!! I'll make sure each an every
one of these observations turning into a bug report...

> 
>> 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.
> 
> 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.
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..

> 
> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Olaf Kirch wrote:
> On Tuesday 24 April 2007 19:52, Steve Dickson wrote:
>> In theory yes...  but unfortunately Transport Independent
>> RPC code is much different than the RPC we have in glibc.
> 
> 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 - 
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...

> 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
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..

> 
>  -	glibc tries to be more multithread friendly, by using
> 	things like gethostbyname_r instead of gethostbyname.
> 	tirpc doesn't.
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...


>  -	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.
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?

> 
>  -	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);
Look again... clp is pointing to global data... so locks
are needed...

> 
>  -	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
educate me... why is using poll() better than select()?

> 
>  -	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.
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?

> 
>  -	tirpc is K&R all over the place, while glibc is mostly
> 	cleaned up (not everywhere though)
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...

> 
>  -	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).
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?

> 	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.
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

> 
>  -	the authunix code in tirpc assumes sizeof(gid_t)
> 	equals sizeof(int)
this is true... are there any modern day machine architecture
where sizeof(gid_t) == sizeof(short)?

> 
>  -	the glibc RPC client side seems to be thread safe, whereas
> 	tirpc seems to be lacking in some areas (see rpc_thread.c)
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...

> 
> I stopped reading the code after an hour, but I think this list could
> be extended quite a bit.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[J. Bruce Fields]

On Thu, Apr 26, 2007 at 06:22:13PM -0400, Steve Dickson wrote:
> Olaf Kirch wrote:
> > 	       mutex_lock(&clntraw_lock);
> > 	       if (clp == NULL) {
> > 	               mutex_unlock(&clntraw_lock);
> > 	               return (RPC_FAILED);
> > 	       }
> > 	       mutex_unlock(&clntraw_lock);
> Look again... clp is pointing to global data... so locks
> are needed...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 27 April 2007 00:22, Steve Dickson wrote:
> 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..

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.

> 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...

getaddrinfo is thread-safe, so that is fine.

> 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...

Ah, okay.

> >  -	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.
> 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?

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.

> >  -	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);
> Look again... clp is pointing to global data... so locks
> are needed...

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.

> >  -	glibc switched to poll(), whereas tirpc still uses
> > 	select with all its limitations
> educate me... why is using poll() better than select()?

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.

> >  -	in tirpc, clnt_sperror uses snprintf to avoid buffer overflows,
> > 	but gets it all wrong wrt the return value of snprintf.
> 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?

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 :-)

> >  -	tirpc is K&R all over the place, while glibc is mostly
> > 	cleaned up (not everywhere though)
> 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 agree it's a matter of taste. Like  wearing bell bottom jeans
and pink shirts :-)

> >  -	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).
> 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?

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++);

> > 
> >  -	the authunix code in tirpc assumes sizeof(gid_t)
> > 	equals sizeof(int)
> this is true... are there any modern day machine architecture
> where sizeof(gid_t) == sizeof(short)?

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.

> Now I did not spend the time just to be argumentative with Olaf...

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

> 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...

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Olaf Kirch wrote:
> On Friday 27 April 2007 00:22, Steve Dickson wrote:
>   
>> 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..
>>     
>
> 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.
>
>   

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.

>> 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...
>>     
>
> Ah, okay.
>
>   

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?


>>>  -	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.
>>>       
>> 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?
>>     
>
> 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.
>
>   

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

>>>  -	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);
>>>       
>> Look again... clp is pointing to global data... so locks
>> are needed...
>>     
>
> 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.
>
>   

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.

>>>  -	glibc switched to poll(), whereas tirpc still uses
>>> 	select with all its limitations
>>>       
>> educate me... why is using poll() better than select()?
>>     
>
> 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.
>
>   

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

>>>  -	in tirpc, clnt_sperror uses snprintf to avoid buffer overflows,
>>> 	but gets it all wrong wrt the return value of snprintf.
>>>       
>> 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?
>>     
>
> 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 :-)
>
>   

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

>>>  -	tirpc is K&R all over the place, while glibc is mostly
>>> 	cleaned up (not everywhere though)
>>>       
>> 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 agree it's a matter of taste. Like  wearing bell bottom jeans
> and pink shirts :-)
>
>   

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.

>>>  -	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).
>>>       
>> 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?
>>     
>
> 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++);
>
>   

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

>>>  -	the authunix code in tirpc assumes sizeof(gid_t)
>>> 	equals sizeof(int)
>>>       
>> this is true... are there any modern day machine architecture
>> where sizeof(gid_t) == sizeof(short)?
>>     
>
> 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.
>   

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

>   
>> Now I did not spend the time just to be argumentative with Olaf...
>>     
>
> No offense taken. I should have probably explained my points
> better than I did
>
>   
>> 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...
>>     
>
> That's where we disagree :-) I think ripping out the glibc
> code and replacing it will cause a lot of maintenance for
> the distros.
>   

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Fri, Apr 27, 2007 at 10:01:53AM -0400, Peter Staubach wrote:
> 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?

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

> >That's where we disagree :-) I think ripping out the glibc
> >code and replacing it will cause a lot of maintenance for
> >the distros.
> >  
> 
> I am curious what basis that you are using for this?  Why will this
> cause either more or less maintenance for distros?

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.

> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Christoph Hellwig wrote:
> On Fri, Apr 27, 2007 at 10:01:53AM -0400, Peter Staubach wrote:
>   
>> 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?
>>     
>
> The README file claims it's a Sun codedrop from 1993 (!)
>
>   

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

>>> That's where we disagree :-) I think ripping out the glibc
>>> code and replacing it will cause a lot of maintenance for
>>> the distros.
>>>  
>>>       
>> I am curious what basis that you are using for this?  Why will this
>> cause either more or less maintenance for distros?
>>     
>
> 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.
>
>   

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.

>> 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.
>>     
>
> 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.
>   

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Christoph Hellwig]

On Fri, Apr 27, 2007 at 10:21:08AM -0400, Peter Staubach wrote:
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Peter Staubach wrote:
>>
>> 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.
>>   
> 
> I had the impression that SteveD had stepped up.  Or am I speaking out of
> turn for him?  :-)
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 27 April 2007 16:01, Peter Staubach wrote:
> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Olaf Kirch wrote:
> On Friday 27 April 2007 16:01, Peter Staubach wrote:
>   
>> 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.
>>     
>
> 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.
>   

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Olaf Kirch]

On Friday 27 April 2007 16:01, Peter Staubach wrote:
> 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.

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.

[...]
> 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?
[...]
> 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.
[...]
> 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.

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.

> > That's where we disagree :-) I think ripping out the glibc
> > code and replacing it will cause a lot of maintenance for
> > the distros.
> 
> I am curious what basis that you are using for this?  Why will this
> cause either more or less maintenance for distros?

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.

> 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.

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
okir@lst.de |    / | \   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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Peter Staubach]

Olaf Kirch wrote:
> On Friday 27 April 2007 16:01, Peter Staubach wrote:
>   
>> 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.
>>     
>
> 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.
>
>   

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.  :-)


> [...]
>   
>> 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?
>>     
> [...]
>   
>> 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.
>>     
> [...]
>   
>> 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.
>>     
>
> You see why I'm arguing against just replacing working code
> with something else, without understanding the ramifications?
>
>   

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.

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

Yes, definitely.  :-)

>>> That's where we disagree :-) I think ripping out the glibc
>>> code and replacing it will cause a lot of maintenance for
>>> the distros.
>>>       
>> I am curious what basis that you are using for this?  Why will this
>> cause either more or less maintenance for distros?
>>     
>
> 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.
>
>   

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

>> 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.
>>     
>
> 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.

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

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

Olaf Kirch wrote:
>>>  -	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.
>> 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?
> 
> 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.
I'm still working on this... but I am wondering why this
would be important.. why look back?

> 
>>>  -	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);
>> Look again... clp is pointing to global data... so locks
>> are needed...
> 
> 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.
commit 419d35db75ab8bd8f79c424f529a6c2f7c4f5fa7
Author: Steve Dickson <steved@redhat.com>
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.

     Signed-off-by: Steve Dickson <steved@redhat.com>


> 
>>>  -	glibc switched to poll(), whereas tirpc still uses
>>> 	select with all its limitations
>> educate me... why is using poll() better than select()?
> 
> 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.
still looking into this... I need to port to some applications
to test this out...

> 
>>>  -	in tirpc, clnt_sperror uses snprintf to avoid buffer overflows,
>>> 	but gets it all wrong wrt the return value of snprintf.
>> 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?
> 
> 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 :-)
commit a3a3a4e5157932c254200e3b31a78739f5878071
Author: Steve Dickson <steved@redhat.com>
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.

     Signed-off-by: Steve Dickson <steved@redhat.com>

>>>  -	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).
>> 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?
> 
> 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++);
commit 83cb8b02f87fe6fd7bbd903e4825f7cb38e59ec4
Author: Steve Dickson <steved@redhat.com>
Date:   Fri May 4 12:19:27 2007 -0400

     A couple ntohs() were needed in bindresvport_sa()

     Signed-off-by: Steve Dickson <steved@redhat.com>

> 
> Two more things:
> 
>  - 	tirpc does a getenv("NETNAME") which should probably be
> 	secure_getenv().
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...

> 
>  -	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.
commit 40ab0c28e995786d5844bd490a31b788ecabf546
Author: Steve Dickson <steved@redhat.com>
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

     Signed-off-by: Steve Dickson <steved@redhat.com>


> 
> That's where we disagree :-) I think ripping out the glibc
> code and replacing it will cause a lot of maintenance for
> the distros.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Portmap - was Re: Does mountd/statd really need to listen on a privileged port??

[Steve Dickson]

Neil Brown wrote:
> On Monday April 23, SteveD@redhat.com wrote:
>>>> 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..
>>> Yes, very hasty.  Several #temporary# and back~ files :-)
>> Yeah... for some reason those temporary files are in the
>> the tar ball... I'll work to get that cleaned up..
> 
> Is there someone "maintaining" rpcbind?  Should there be?
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..

> 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?
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...

> 
> 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?
> 
>>> 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....
>> I'm not sure I understand.. are you talking about how getowner()
>> is being used?
> 
> 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.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Steve Dickson]

Neil Brown wrote:
> 
> 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.
I agree...

> 
> Portmap appeared to be a 10 year old program that each distro
> maintains their own copy of...
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).

> 
> 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?
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[J. Bruce Fields]

On Thu, Apr 19, 2007 at 11:15:32AM -0400, Steve Dickson wrote:
> Neil Brown wrote:
> > 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?
> 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...

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Steve Dickson]

J. Bruce Fields wrote:
> On Thu, Apr 19, 2007 at 11:15:32AM -0400, Steve Dickson wrote:
>> Neil Brown wrote:
>>> 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?
>> 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...
> 
> 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?
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[J. Bruce Fields]

On Thu, Apr 19, 2007 at 11:42:27AM -0400, Steve Dickson wrote:
> J. Bruce Fields wrote:
> >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?
> 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?

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Steve Dickson]

J. Bruce Fields wrote:
> On Thu, Apr 19, 2007 at 11:42:27AM -0400, Steve Dickson wrote:
>> J. Bruce Fields wrote:
>>> 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?
>> 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?
> 
> 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.
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...

> 
> But maybe there's no particular advantage to having the two together
> anyway.
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Anibal Monsalve Salazar]

[-- Attachment #1.1: Type: text/plain, Size: 2013 bytes --]

On Thu, Apr 19, 2007 at 12:36:50PM -0400, Steve Dickson wrote:
>J. Bruce Fields wrote:
>>On Thu, Apr 19, 2007 at 11:42:27AM -0400, Steve Dickson wrote:
>>>J. Bruce Fields wrote:
>>>>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?

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.

>>>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?
>>
>>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.

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.

>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...
>>
>>But maybe there's no particular advantage to having the two together
>>anyway.
>I really don't see any...  I think it would become for a headache
>than its worth...
>
>steved.

Anyway, I like Neil's proposal. :)

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs