]> git.neil.brown.name Git - portmap.git/commit
Only fail an 'unregister' attempt if nothing can be unregistered. master
authorDenis Zaitceff <zaitceff@gmail.com>
Fri, 20 Jun 2014 17:09:26 +0000 (23:09 +0600)
committerNeil Brown <neilb@suse.de>
Mon, 23 Jun 2014 01:19:03 +0000 (11:19 +1000)
commit4836a4aa7cec4fe515a61b70d6cb24ed2348955a
tree34dbae63314a8c59afbb5bc86d930ec2746d932c
parent026c8f47bbaf401c93f5e14b560746ef724a8161
Only fail an 'unregister' attempt if nothing can be unregistered.

It is possible that the registration for some protocol can be
unregistered by a given request, but others cannot.
Currently we abort if we find something that cannot be unregistered,
even if we have already successfuly unregistered something else.
It is better to unregister whatever we can, and return success if
anything was successful.

Original comment:

There is some inconsistency(-alike?) in the portmap protocol:

a) PMAPPROC_SET registers the only one program using the
 (prog,vers,prot) key, while PMAPPROC_UNSET unregisters all the (two)
 programs, as it uses just the (prog,vers) key.

b) Then, it seems to be pretty legal, if two different processes SET
 the same (prog,vers) tuples - one for TCP and another for UDP.

And at the UNSET step, portmap can catch some security question: say,
one process has been used the privileged port for registration, while
another process has not.  And, considering b), portmap must refuse to
UNSET the privileged port if it was asked by unprivileged port's
process.  And this should not be considered as an error, while ever
one port is UNSET.  But in the current implementation, that "mixed"
cases are treated as just an error.  The patch fixes this behaviour.
Please apply it, if my understanding is correct.

Signed-off-by: Neil Brown <neilb@suse.de>
from_local.c
portmap.c