[Bug 304393] Re: rpcbind grabs ports used by other daemons such as cupsd
Dan Streetman
304393 at bugs.launchpad.net
Tue Aug 4 21:13:43 UTC 2020
** Description changed:
[impact]
rpcbind binds to a 'random' reserved port at startup, which can conflict
with the reserved port number for other applications that actually 'own'
the reserved port number. One example is cups, which uses the reserved
port 631.
This prevents the actual 'owner' of the reserved port from starting,
since it can't bind to its reserved port.
Additionally, this can raise alarms from security monitoring software
that does not expect programs to be listening on random reserved ports.
[test case]
start rpcbind and check which ports it is listening on, e.g.:
$ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc
udp 0 0 0.0.0.0:614 0.0.0.0:* 4678/rpcbind
each time rpcbind is restarted, it will be listening to a different
'random' port.
[regression potential]
this adds a way to disable rpcbind from listening to the 'random' port.
any regression would likely prevent rpcbind from starting, or may cause
problems with the interaction between rpcinfo and rpcbind, as rpcinfo
may use the random reserved port in some cases, as detailed in the
Debian bug.
[scope]
This is needed only for Bionic and earlier.
In Focal and later, and in Debian, rpcbind defaults to not opening the
random reserved port. The admin can use the -r parameter to cause
rpcbind to restore the old behavior of opening the random reserved port.
[other info]
Note that the -r parameter is a Debian addition, and the upstream
rpcbind has disabled the random port functionality at build time; there
is no runtime parameter to allow the admin to choose the behavior.
Also, as discussed in the Debian bug, disabling this rpcbind 'feature'
is known to cause problems for the rpcinfo program, which is why Debian
introduced the -r parameter. So, when this -r parameter is backported to
Bionic and earlier, we must retain the default behavior for those
releases, which is for rpcbind to open the random reserved port.
Thus, the patch for this will first backport the upstream patch that adds functionality to be able to disable the 'remote calls' function, and also backports the debian patch to change that from a compile-time to run-time option. Then, another patch is added, which changes the default back to the behavior of x/b, which is for remote calls to be enabled by default,
- and also adds a check for the existence of an environment variable "RPCBIND_RMTCALLS_DEFAULT_DISABLED" which, if defined (to anything), will change the default to disabled.
+ and also adds a check for the existence of an environment variable "RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change the default to disabled.
This allows 1) retaining the existing default behavior of rpcbind in x
and b, while also 2) providing a mechanism to change that default for
anyone who does *not* want remote calls to be enabled, and 3) allowing
the mechanism to change the default to remain in place after an upgrade
to Focal. Using the environment variable, instead of changing or adding
the cmdline parameter, allows anyone using the variable to disable the
remote calls default to upgrade to Focal without breaking rpcbind. After
the upgrade to Focal, the environment variable (defined in
/etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored
without any change needed to the rpcbind package in Focal or later.
[original description]
As this backports that functionality, it
Binary package hint: cups
cups 1.3.9-2ubuntu4
From /var/log/cups/error_log:
cups: unable to bind socket for address 127.0.0.1:631 - Address already in use.
Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when
started.
** Description changed:
[impact]
rpcbind binds to a 'random' reserved port at startup, which can conflict
with the reserved port number for other applications that actually 'own'
the reserved port number. One example is cups, which uses the reserved
port 631.
This prevents the actual 'owner' of the reserved port from starting,
since it can't bind to its reserved port.
Additionally, this can raise alarms from security monitoring software
that does not expect programs to be listening on random reserved ports.
[test case]
start rpcbind and check which ports it is listening on, e.g.:
$ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc
udp 0 0 0.0.0.0:614 0.0.0.0:* 4678/rpcbind
each time rpcbind is restarted, it will be listening to a different
'random' port.
[regression potential]
this adds a way to disable rpcbind from listening to the 'random' port.
any regression would likely prevent rpcbind from starting, or may cause
problems with the interaction between rpcinfo and rpcbind, as rpcinfo
may use the random reserved port in some cases, as detailed in the
Debian bug.
[scope]
This is needed only for Bionic and earlier.
In Focal and later, and in Debian, rpcbind defaults to not opening the
random reserved port. The admin can use the -r parameter to cause
rpcbind to restore the old behavior of opening the random reserved port.
[other info]
Note that the -r parameter is a Debian addition, and the upstream
rpcbind has disabled the random port functionality at build time; there
is no runtime parameter to allow the admin to choose the behavior.
Also, as discussed in the Debian bug, disabling this rpcbind 'feature'
is known to cause problems for the rpcinfo program, which is why Debian
introduced the -r parameter. So, when this -r parameter is backported to
Bionic and earlier, we must retain the default behavior for those
releases, which is for rpcbind to open the random reserved port.
Thus, the patch for this will first backport the upstream patch that adds functionality to be able to disable the 'remote calls' function, and also backports the debian patch to change that from a compile-time to run-time option. Then, another patch is added, which changes the default back to the behavior of x/b, which is for remote calls to be enabled by default,
and also adds a check for the existence of an environment variable "RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change the default to disabled.
This allows 1) retaining the existing default behavior of rpcbind in x
and b, while also 2) providing a mechanism to change that default for
anyone who does *not* want remote calls to be enabled, and 3) allowing
the mechanism to change the default to remain in place after an upgrade
- to Focal. Using the environment variable, instead of changing or adding
- the cmdline parameter, allows anyone using the variable to disable the
- remote calls default to upgrade to Focal without breaking rpcbind. After
- the upgrade to Focal, the environment variable (defined in
- /etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored
- without any change needed to the rpcbind package in Focal or later.
+ to Focal. Using the environment variable allows anyone to disable the
+ remote calls in x and/or b, and then upgrade to Focal without breaking
+ rpcbind or needing to remove the env var. After the upgrade to Focal,
+ the environment variable (defined in /etc/default/rpcbind and/or
+ /etc/rpcbind.conf) will simply be ignored without any change needed to
+ the rpcbind package in Focal or later.
[original description]
-
- As this backports that functionality, it
Binary package hint: cups
cups 1.3.9-2ubuntu4
From /var/log/cups/error_log:
cups: unable to bind socket for address 127.0.0.1:631 - Address already in use.
Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when
started.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rpcbind in Ubuntu.
https://bugs.launchpad.net/bugs/304393
Title:
rpcbind grabs ports used by other daemons such as cupsd
Status in cups package in Ubuntu:
Invalid
Status in rpcbind package in Ubuntu:
Fix Released
Status in rpcbind source package in Xenial:
In Progress
Status in rpcbind source package in Bionic:
In Progress
Status in rpcbind package in Debian:
Fix Released
Status in Fedora:
Confirmed
Bug description:
[impact]
rpcbind binds to a 'random' reserved port at startup, which can
conflict with the reserved port number for other applications that
actually 'own' the reserved port number. One example is cups, which
uses the reserved port 631.
This prevents the actual 'owner' of the reserved port from starting,
since it can't bind to its reserved port.
Additionally, this can raise alarms from security monitoring software
that does not expect programs to be listening on random reserved
ports.
[test case]
start rpcbind and check which ports it is listening on, e.g.:
$ sudo netstat --inet -p -l | grep rpcbind | grep -v sunrpc
udp 0 0 0.0.0.0:614 0.0.0.0:* 4678/rpcbind
each time rpcbind is restarted, it will be listening to a different
'random' port.
[regression potential]
this adds a way to disable rpcbind from listening to the 'random'
port. any regression would likely prevent rpcbind from starting, or
may cause problems with the interaction between rpcinfo and rpcbind,
as rpcinfo may use the random reserved port in some cases, as detailed
in the Debian bug.
[scope]
This is needed only for Bionic and earlier.
In Focal and later, and in Debian, rpcbind defaults to not opening the
random reserved port. The admin can use the -r parameter to cause
rpcbind to restore the old behavior of opening the random reserved
port.
[other info]
Note that the -r parameter is a Debian addition, and the upstream
rpcbind has disabled the random port functionality at build time;
there is no runtime parameter to allow the admin to choose the
behavior.
Also, as discussed in the Debian bug, disabling this rpcbind 'feature'
is known to cause problems for the rpcinfo program, which is why
Debian introduced the -r parameter. So, when this -r parameter is
backported to Bionic and earlier, we must retain the default behavior
for those releases, which is for rpcbind to open the random reserved
port.
Thus, the patch for this will first backport the upstream patch that adds functionality to be able to disable the 'remote calls' function, and also backports the debian patch to change that from a compile-time to run-time option. Then, another patch is added, which changes the default back to the behavior of x/b, which is for remote calls to be enabled by default,
and also adds a check for the existence of an environment variable "RPCBIND_RMTCALL_DEFAULT_DISABLED" which, if defined (to anything), will change the default to disabled.
This allows 1) retaining the existing default behavior of rpcbind in x
and b, while also 2) providing a mechanism to change that default for
anyone who does *not* want remote calls to be enabled, and 3) allowing
the mechanism to change the default to remain in place after an
upgrade to Focal. Using the environment variable allows anyone to
disable the remote calls in x and/or b, and then upgrade to Focal
without breaking rpcbind or needing to remove the env var. After the
upgrade to Focal, the environment variable (defined in
/etc/default/rpcbind and/or /etc/rpcbind.conf) will simply be ignored
without any change needed to the rpcbind package in Focal or later.
[original description]
Binary package hint: cups
cups 1.3.9-2ubuntu4
From /var/log/cups/error_log:
cups: unable to bind socket for address 127.0.0.1:631 - Address already in use.
Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd
when started.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions
More information about the foundations-bugs
mailing list