Andi,

I wrote the following description of the core_pattern pipe feature.  Does this
seem okay?

   Piping core dumps to a program
       Since kernel 2.6.19, Linux supports an  alternate  syntax
       for the /proc/sys/kernel/core_pattern file.  If the first
       character of this file is a pipe  symbol  (|),  then  the
       remainder  of  the line is interpreted as a program to be
       executed.  Instead of being written to a disk  file,  the
       core  dump  is  given  as  standard input to the program.
       Note the following points:

       *  The program must be specified using an absolute  path-
          name  (or  a  pathname relative to the root directory,
          /), and must immediately follow the '|' character.

       *  The process created to run the program  runs  as  user
          and group root.

       *  Arguments can be supplied to the program, delimited by
          white space (up to a total line length of 128  bytes).

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug?  Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html

--

Andi -- ping!

Adding Neil to CC, since it looks like he also did some work here, and
so can perhaps comment.

On Fri, Apr 18, 2008 at 6:53 PM, Michael Kerrisk



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--

Thanks for CC'ing me.  The above all looks good.  I would add documentation
however, about the available macros that can be used when core_pattern is
specified as a pipe.  Adding something like the following would be good:

	* Arguments can be statically declared or implied via the use of macros,
	  denoted by the use of the %sign.  The following macros are supported:
		* %% - output a literal % sign on the command line
		* %p - the pid of the crashing process
		* %u - the uid of the crashing process
		* %g - the gid of the crashing process
		* %s - the signal that caused the crashing process to crash
		* %t - the time the crashing process dumped
		* %h - the hostname of the system
		* %e - the executable name of the crashing process
		* %c - the core limit size of the crashing process

	  Note that the core limit size macro may be a different value than what
	  is returned by getrlimit(RLIMIT_CORE,...).  This is due to the fact
	  that the core_pattern specified executible will be run as the same uid
	  as the crashing process, and to facilitate reception of the entire
	  core, the kernel will temporarily set RLIMIT_CORE to unlimited while
	  the dump is in progress.  Note also %u and %g may be different values
	  than getuid/getgid in the event that the core_pattern executable is
	  set[u|g]id root


Thanks & Regards
Neil


-- 
/***************************************************
 *Neil Horman
 *nhorman@tuxdriver.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
--

Hi Neil,



Actually, I can't seem to get an example of this behavior.  In my
experiments, %c always seems to give the "right" info (i.e., I don't
ever see %c showing 2^32 (unlimited) when I set a soft limit).  Can

I'm slightly confused by that last point.  According to my
experiments, the core_pattern executable is always run as user and
group root, so making it set[ug]id root would seem to be a no-op.
(But anyway, %u and %g do give the "right" values -- the UID and GID
of the dumping process.)

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--

Oops, you're right.  I had initially implemented my core pattern updates this
way, but in the end wound up just ignoring the limit in do_coredump, rather than
Hmm, are you sure, I was under the impression that we fork the usermodehelper in
do_coredump as a parent of current, which has the dumping processes uid/gid.  I
do see that in do_coredump we call get_dumpable(mm) and if it returns with the
appropriate value we switch current->fsuid to 0.  I wonder if thats what you're
seeing?

Thanks & Regards

-- 
/****************************************************
 * Neil Horman <nhorman@tuxdriver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--

Have a look at the following.  It demonstrates what I'm seeing (that
the coredump program is run as root/root).

===
$ cat core_pattern_test.c
/* core_pattern_test.c */

#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define BUF_SIZE 1024

int
main(int argc, char *argv[])
{
    int fd, tot, j;
    ssize_t nread;
    char buf[BUF_SIZE];
    FILE *fp;

    fd = open(argv[1], O_CREAT | O_WRONLY | O_TRUNC, 0666);
    if (fd == -1)
        exit(EXIT_FAILURE);

    fp = fdopen(fd, "a");

    fprintf(fp, "PID=%ld\n", (long) getpid());
    fprintf(fp, "cwd=%s\n", get_current_dir_name());
    fprintf(fp, "UID=%ld; EUID=%ld\n", (long) getuid(), (long) geteuid());
    fprintf(fp, "GID=%ld; EGID=%ld\n", (long) getgid(), (long) getegid());

    fprintf(fp, "argc=%d\n", argc);
    for (j = 0; j < argc; j++)
        fprintf(fp, "argc[%d]=<%s>\n", j, argv[j]);

    /* Count bytes in standard input */

    tot = 0;
    while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)
        tot += nread;
    fprintf(fp, "Total bytes in core dump: %d\n", tot);

    exit(EXIT_SUCCESS);
}
$ cc core_pattern_test.c
$ sudo sh -c 'echo "|$PWD/core_pattern_test $PWD/c p_%p u_%u g_%g t_%t
c_%c" > /proc/sys/kernel/core_pattern'
root's password:
$ id
uid=1000(mtk) gid=100(users) groups=16(dialout),33(video),100(users)
$ sleep 100
[type ^\]
Quit (core dumped)
$ cat c
PID=6743
cwd=/
UID=0; EUID=0
GID=0; EGID=0
argc=7
argc[0]=</home/mtk/man-pages/man5/core_pattern_test>
argc[1]=</home/mtk/man-pages/man5/c>
argc[2]=<p_6742>
argc[3]=<u_1000>
argc[4]=<g_100>
argc[5]=<t_1209146940>
argc[6]=<c_4294967295>
Total bytes in core dump: 282624
$
===

Your thoughts?

Cheers,

Michael
--

I certainly don't doubt your results.  The uid/gid options IIRC were there when
I made my updates and so I left them alone, wokring under the asumption that
thats what they were there for.  Clearly you have evidence to the contrary here.
It seems like we should run the core collector as the uid of the dumping
process, simply because it doesn't need to be run as root (and one could force
the running of the commadn as root using the suid bit on the executable file).

I say documented like your experiment shows it to work, and I'll try to find
some time to investigate where we switch uids and why.

Thanks for the info!
Neil

-- 
/****************************************************
 * Neil Horman <nhorman@tuxdriver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--

There was another aspect of this behavior that bugs me.  The current
working directory of the dumping program is /.  This means it's
impossible for the dumping program to produce an output file in the
current working directory of the program that is crashing (which of
course is where a "core" file is normally written).  Is that really
intended behavior?
--

I'm a bit hazy, but IIRC, the idea was that for environment stuff, as long as
you had the pid of the crashing process (which you do), you can grab the rest of
the environment out of /proc/<pid>/environ

Regards
Neil

-- 
/****************************************************
 * Neil Horman <nhorman@tuxdriver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--

Thanks for that point -- tested, and that works.  It is kind of obtuse
as a method of getting the current working directory though...
--

Hi Neil,

Below is a revised draft of the text for core_pattern.  Would you be willing
check it over?

Cheers,

Michael

     Naming of core dump files
       By   default,   a  core  dump  file  is  named  core,  but  the
       /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21)
       can  be set to define a template that is used to name core dump
       files.  The template can contain % specifiers which are substi-
       tuted by the following values when a core file is created:

           %%  a single % character
           %p  PID of dumped process
           %u  (numeric) real UID of dumped process
           %g  (numeric) real GID of dumped process
           %s  number of signal causing dump
           %t  time  of  dump,  expressed  as  seconds since the Epoch
               (00:00h, 1 Jan 1970, UTC)
           %h  hostname (same as 'nodename' returned by uname(2))
           %e  executable filename (without path prefix)
           %c  core file size soft resource limit of crashing  process
               (since Linux 2.6.24)

       A  single % at the end of the template is dropped from the core
       filename, as is the combination of a % followed by any  charac-
       ter other than those listed above.  All other characters in the
       template become a literal part of the core filename.  The  tem-
       plate  may  include  '/'  characters,  which are interpreted as
       delimiters for  directory  names.   The  maximum  size  of  the
       resulting  core  filename  is  128  bytes  (64 bytes in kernels
       before 2.6.19).
   [...]

     Piping core dumps to a program
       Since kernel 2.6.19, Linux supports an alternate syntax for the
       /proc/sys/kernel/core_pattern  file.  If the first character of
       this file is a pipe symbol (|), then the remainder of the  line
       is  interpreted  as a program to be executed.  Instead of being
       written to a disk file, the core  dump  is  given  as  standard
       input to...
[ message continues ]

All looks great to me, thanks!

Acked-by: Neil Horman <nhorman@tuxdriver.com>


-- 
/****************************************************
 * Neil Horman <nhorman@tuxdriver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--

Andi, Can you offer any input on the last topic in the message below?




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--