On Wednesday April 18, [email protected] wrote:
> On Tuesday April 17, [email protected] 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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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