Re: [NSE] rpc library; Portmapper program list stored in the

[Djalal Harouni <tixxdz () gmail com>]

On 2010-05-04 12:14:00 -0600, David Fifield wrote:
> On Fri, Apr 30, 2010 at 12:13:03PM +0200, Patrik Karlsson wrote:
> > Hi Djalal,
> >
> > I tested the patch against a Linux server running NFS and it works great.
> > My virtual OS X server behaves as badly as last time, so I don't think
> > it makes a good reference.
> > If someone else has the possibility to try this patch out against OS X
> > please let us know.
>
> I have tried it against OS X 10.6.3 with the result
>
> PORT    STATE SERVICE REASON
> 111/tcp open  rpcbind syn-ack
> | rpcinfo:
> |   100000  2            111/tcp  rpcbind
> |   100000  2            111/udp  rpcbind
> |   100003  2,3         2049/tcp  nfs
> |   100003  2,3         2049/udp  nfs
> |   100005  1,3          688/udp  mountd
> |   100005  1,3         1023/tcp  mountd
> |   100011  1,2          960/udp  rquotad
> |   100021  0,1,3,4      902/udp  nlockmgr
> |   100021  0,1,3,4     1022/tcp  nlockmgr
> |   100024  1            831/udp  status
> |_  100024  1           1021/tcp  status
> | nfs-showmount:
> |_  /Users/david 192.168.0.0
> | nfs-acls:
> |   /Users/david
> |_    ERROR: Mount: RPC call failed: remote can't authenticate caller.
> | nfs-dirlist:
> |   /Users/david
> |_    ERROR: Mount: RPC call failed: remote can't authenticate caller.
> | nfs-statfs:
> |   /Users/david
> |_    ERROR: Mount: RPC call failed: remote can't authenticate caller.
>
> I don't know what I have to do to get the authentication to work.
The current version of the RPC library support only NULL authentication
and doesn't show the authentication stats and error messages. These
improvements are in my TODO list.

> The caching patch looks fine and you can commit it, but I don't see the
> reason to add dependencies on rpcinfo. This will have no effect when
> rpcinfo isn't run. Since it's a cache, it seems whoever gets the
> information first should cache it, whether it's an rpc or an nfs script.
I simply wanted to use a logical order and to print the rpcinfo results
before others nfs-* results.

> > So, a weak keyed table, suggested by Patrick, is probably the best bet.
>
> It sounds like a good idea. Again, this is just a cache, an
> optimization, so it's not the end of the world if a weak key is removed
> from the cache and we have to re-send a probe.
I'll write another patch to use weak tables, for the moment I'm busy
with gsoc priorities and reading the Pil doc.

> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

-- 
tixxdz
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/