Well, the consensus seems to be that a new 'upstream' would not be a
bad thing, but that including it in nfs-utils might not be the best
idea.
I can live with that, and would like to nominate myself as the new
upstream source for 'portmap'. Does anyone object?
I have created a git repository that can be accessed via:
git://neil.brown.name/portmap
or
http://neil.brown.name/git?p=portmap (for browsing).
It starts with the '5beta' tarball that both SuSE and Debian use
(Fedora uses a slightly older version 4 tarball).
It then adds a host of fixes which cover almost everything I can find
in the Debian, SuSE, and Fedora packages.
The only conflict was the SuSE and Fedora chose a syslog facility of
'AUTH' while Debian chose 'DAEMON' (the original tarball has 'MAIL').
'DAEMON' makes most sense to me, so that is in the .git.
There are two patches from Fedora that I have not included.
One uses 'getpwnam("rpc")' to find a uid to 'setuid' to.
This could be a problem is NIS is in use and 'rpc' isn't in
/etc/passwd - portmap would be need to find the NIS server to check
for 'rpc' before portmap could start.
Maybe we should make the uid a compile-time option?
The other uses gethostbyname to allow tcpwrappers to provide host-name
based access control. This is similarly a potential ground for
deadlocks, and the man page from Debian explicitly says that isn't
supported so presumably a Debian maintainer has thought about it.
Maybe we could add a compile-time option to enable this if Fedora
really wants it.
Also I have made two enhancements of my own (which is the whole point
of doing this).
Firstly, registrations made with a privileged port are flagged as
such, and can only be deregistered with a request from a privileged
port. That makes it safe for statd/mountd etc to listen on
unprivileged ports.
The only down side I can see to this is if the sysadmin uses:
pmap_dump
kill
restart
pmap_set
to restart portmap, all the ports will appear to be registered by a
privileged user, so a non-root user who is expecting to be able to
unregister a port will not be able to.
Partly to address this, and partly because I think it is a good idea,
portmap now keeps a copy of it's mapping table in
/var/run/portmap_mapping (even when it chroots elsewhere) and will
reload it on restart. So pmap_dump/pmap_set is no longer needed.
After any discussion/resolution on the missing Fedora patches, and
maybe some testing/review by others, I would like to make a new
release (maybe called 6.0), announce it on freshmeat, and put a
tar-ball somewhere. Then nfs-utils-1.1.0 will recommend that
portmap-6.0 be a dependency as mountd no longer listens on a
privileged port.
Comments/review/suggestions welcome.
Thanks for your time.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs