group.of.nepali.translators team mailing list archive

[Dan Streetman <304393@xxxxxxxxxxxxxxxxxx>]

** 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 method 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.
+ 
+ TBD: specific method to disable rmtcalls in backport
+ 
+ 
+ [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.

** Changed in: rpcbind (Ubuntu Bionic)
     Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: rpcbind (Ubuntu Xenial)
     Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: rpcbind (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: rpcbind (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: rpcbind (Ubuntu Bionic)
       Status: New => In Progress

** Changed in: rpcbind (Ubuntu Xenial)
       Status: New => In Progress

** Changed in: rpcbind (Ubuntu)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Unknown
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 method 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.

  TBD: specific method to disable rmtcalls in backport

  
  [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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions