[Bug 1732962] Re: apport uses sys.argv instead of named arguments

[Matthieu Clemenceau]

** Description changed:

+ SRU Description
+ 
+ [Impact]
+ data/apport which processes core files expects a certain quantity of arguments in a specific order. This ended up causing an issue with some security updates where we were trying to support a new version of apport on a host system and one inside a container. 
+ This SRU for xenial and bionic based on the work made in cosmic enabled proper handling of named argument.
+ Note that this is disabled for now on ALL series
+  
+ [Test Case]
+ No real test here since apport general behavior should be unchanged Just to check that the feature is disable, /proc/sys/kernel/core_pattern
+ content should remain unchanged :
+ 
+ $> cat /proc/sys/kernel/core_pattern
+ |/usr/share/apport/apport %p %s %c %d %P %E
+ 
+ [Regression Potential]
+ The new feature is not enabled so the regression risk is fairly low. this will take place in a future coordinated SRU across all LTS but in the meanwhile we can make sure that there's no regression by running apport with various 
+ 
+ End SRU Description
+ 
  data/apport which processes core files expects a certain quantity of
  arguments in a specific order. This ended up causing an issue with some
  security updates where we were trying to support a new version of apport
  on a host system and one inside a container.  Here's something of an
  example:
  
  347 # Normal startup
  348 if len(sys.argv) not in (5, 6):
  349     try:
  350         print('Usage: %s <pid> <signal number> <core file ulimit> <dump mode> [global pid]' % sys.argv[0])
  351         print('The core dump is read from stdin.')
  
  We could not maintain backwards compatibility because "global pid" is an
  optional argument and "dump mode" was a new argument. So if there were
  five arguments its possible the last one was "dump mode" (no global pid)
  or "global pid" (no support for dump mode).
  
  Its possible to use strings in /proc/sys/kernel/core_pattern so we could
  use those and have apport accept named arguments e.g:
  
  $ cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d --global-pid=%P
  
  ['/home/bdmurray/source-trees/apport/artful/data/apport', '--pid=5870',
  '--signal=11', '--core-size=0', '--dump-mode=1', '--global-pid=5870']
  
  Tyler said "that's probably a nice cleanup to make no matter what
  because the magic arg ordering is dangerous".

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1732962

Title:
  apport uses sys.argv instead of named arguments

Status in Apport:
  Fix Committed
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Trusty:
  Won't Fix
Status in apport source package in Xenial:
  In Progress
Status in apport source package in Bionic:
  In Progress
Status in apport source package in Cosmic:
  Won't Fix
Status in apport source package in Disco:
  Fix Released

Bug description:
  SRU Description

  [Impact]
  data/apport which processes core files expects a certain quantity of arguments in a specific order. This ended up causing an issue with some security updates where we were trying to support a new version of apport on a host system and one inside a container. 
  This SRU for xenial and bionic based on the work made in cosmic enabled proper handling of named argument.
  Note that this is disabled for now on ALL series
   
  [Test Case]
  No real test here since apport general behavior should be unchanged Just to check that the feature is disable, /proc/sys/kernel/core_pattern
  content should remain unchanged :

  $> cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport %p %s %c %d %P %E

  [Regression Potential]
  The new feature is not enabled so the regression risk is fairly low. this will take place in a future coordinated SRU across all LTS but in the meanwhile we can make sure that there's no regression by running apport with various 

  End SRU Description

  data/apport which processes core files expects a certain quantity of
  arguments in a specific order. This ended up causing an issue with
  some security updates where we were trying to support a new version of
  apport on a host system and one inside a container.  Here's something
  of an example:

  347 # Normal startup
  348 if len(sys.argv) not in (5, 6):
  349     try:
  350         print('Usage: %s <pid> <signal number> <core file ulimit> <dump mode> [global pid]' % sys.argv[0])
  351         print('The core dump is read from stdin.')

  We could not maintain backwards compatibility because "global pid" is
  an optional argument and "dump mode" was a new argument. So if there
  were five arguments its possible the last one was "dump mode" (no
  global pid) or "global pid" (no support for dump mode).

  Its possible to use strings in /proc/sys/kernel/core_pattern so we
  could use those and have apport accept named arguments e.g:

  $ cat /proc/sys/kernel/core_pattern
  |/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d --global-pid=%P

  ['/home/bdmurray/source-trees/apport/artful/data/apport', '--
  pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
  pid=5870']

  Tyler said "that's probably a nice cleanup to make no matter what
  because the magic arg ordering is dangerous".

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+subscriptions