Comment 5 for bug 160999

Upon further investigation, it looks like the Linux kernel opens the core file with "O_CREAT | O_NOFOLLOW | O_LARGEFILE", then performs the checks listed core(5): http://lxr.linux.no/linux+v2.6.26.3/fs/exec.c#L1749

Apport appears to change its uid/gid to the failing process, then tries to open the core file with "O_WRONLY | O_CREAT | O_EXCL". This takes care of the permission check specified in core(5), but it doesn't handle any of the others. In particular, using O_EXCL, means it doesn't overwrite pre-existing core files, which is the source of my original complaint.

core(5) says core files should be created except in the following cases:

       * The process does not have permission to write the core file.
              (By default the core file is called core, and is created in the
              current working directory. See below for details on naming.)
              Writing the core file will fail if the directory in which it is
              to be created is non-writable, or if a file with the same name
              exists and is not writable or is not a regular file (e.g., it is
              a directory or a symbolic link).

       * A (writable, regular) file with the same name as would be used
              for the core dump already exists, but there is more than one
              hard link to that file.

       * The file system where the core dump file would be created is
              full; or has run out of inodes; or is mounted read only; or the
              user has reached their quota for the file system.

       * The directory in which the core dump file is to be created does
              not exist.

       * RLIMIT_CORE or RLIMIT_FSIZE resource limits for a process are
              set to zero (see getrlimit(2)).

       * The binary being executed by the process does not have read per‐
              mission enabled.

       * The process is executing a set-user-ID (set-group-ID) program
              that is owned by a user (group) other than the real user (group)
              ID of the process. (However, see the description of the
              prctl(2) PR_SET_DUMPABLE operation, and the description of the
              /proc/sys/fs/suid_dumpable file in proc(5).)

My patch doesn't address any of these, and should be ignored.

Ether Apport should be updated to conform to these cases, or the core(5) man page should be updated to note Apport's behavior.