core_pattern piping strangeness

core_pattern piping strangeness

[Michael Kerrisk]

Hi Andi,

In 2.6.19 you added the pipiing syntax
(http://lwn.net/Articles/195310/) to core_pattern.  Petr pointed out
that this is not yet documented in core(5), so I set to testing it.

The change log has the text:

    The core dump proces will run with the privileges and in the name space
    of the process that caused the core dump.

This appears not to be true (as tested on 2.6.25-rc8).  Instead the
pipe program is run as root.  I'm not sure what "in the name space of
the process that caused the core dump" means -- I wondered if it might
mean that the current working directory of the program would be the
same as that of the process that caused the core dump.  However that
is not so: the current directory for the pipe program is the root
directory.

Can you comment?  Am I misunderstanding something?

Test program and shell session shown below.

Cheers,

Michael


$ 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;
    ssize_t numRead;
    char buf[BUF_SIZE];
    FILE *fp;

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

    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());

    /* Count bytes in standard input */

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

    exit(EXIT_SUCCESS);
}

$ cc core_pattern_test.c
$ su
Password:
# echo "|$PWD/a.out $PWD/core.log" > /proc/sys/kernel/core_pattern
# exit
$ sleep 100 &
[1] 5637
$ kill -QUIT %1
[1]+  Quit                    (core dumped) sleep 100
$ cat core.log
PID=5638
cwd=/
UID=0; EUID=0
Total bytes in core dump: 282624

core_pattern pipe documentation

[Michael Kerrisk]

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


Andi Kleen wrote:
> Michael Kerrisk wrote:
>> On Tue, Apr 15, 2008 at 11:09 PM, Michael Kerrisk
>> <mtk.manpages@googlemail.com> wrote:
>>> Hi Andi,
>>>
>>> In 2.6.19 you added the pipiing syntax
>>> (http://lwn.net/Articles/195310/) to core_pattern.  Petr pointed out
>>> that this is not yet documented in core(5), so I set to testing it.
>>>
>>> The change log has the text:
>>>
>>>    The core dump proces will run with the privileges and in the name space
>>>    of the process that caused the core dump.
> 
> My memory is fuzzy but something might have changed this afterwards
> (there were some semantics changes afterwards by other people)  I think
> my original version ran as non root.
> 
> Anyways the reference as usual is the code, not the change log.
> 
>>> This appears not to be true (as tested on 2.6.25-rc8).  Instead the
>>> pipe program is run as root.  I'm not sure what "in the name space of
>>> the process that caused the core dump" means 
> 
> namespace is a concept from plan9. It basically means the tree
> of mounts the current process has access to. On 99+% of the systems
> that is only a single global tree, but there is support for processes
> creating their own name space using clone CLONE_NEWNS and then
> mount/umount/mount --bind etc. Linux VFS had this support for
> some time.
> 
> The whole thing is very obscure but perhaps some more
> coverage in the man pages would be not bad. It seems to move
> slowly out of obscurity now with all the new container work.
> 
> There is some scattered information in Documentation/*. You'll need
> someone else to explain you all the finer details though.
> 
> Also there are lots of different mounts now since a few 2.6 kernels --
> to be honest I don't understand what they are all good for.
> 
> 
> -- I wondered if it might
>>> mean that the current working directory of the program would be the
>>> same as that of the process that caused the core dump.  However that
>>> is not so: the current directory for the pipe program is the root
>>> directory.
> 
> Basically with a different namespace the paths can change completely,
> which can in theory have some unpleasant effects on the core dumper
> script. I skimped this by just always using the same as the process.
> 
> -Andi
> 
> 

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

Re: core_pattern pipe documentation

[Michael Kerrisk]

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
<mtk.manpages@googlemail.com> wrote:
> 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
>
>
> Andi Kleen wrote:
> > Michael Kerrisk wrote:
> >> On Tue, Apr 15, 2008 at 11:09 PM, Michael Kerrisk
> >> <mtk.manpages@googlemail.com> wrote:
> >>> Hi Andi,
> >>>
> >>> In 2.6.19 you added the pipiing syntax
> >>> (http://lwn.net/Articles/195310/) to core_pattern.  Petr pointed out
> >>> that this is not yet documented in core(5), so I set to testing it.
> >>>
> >>> The change log has the text:
> >>>
> >>>    The core dump proces will run with the privileges and in the name space
> >>>    of the process that caused the core dump.
> >
> > My memory is fuzzy but something might have changed this afterwards
> > (there were some semantics changes afterwards by other people)  I think
> > my original version ran as non root.
> >
> > Anyways the reference as usual is the code, not the change log.
> >
> >>> This appears not to be true (as tested on 2.6.25-rc8).  Instead the
> >>> pipe program is run as root.  I'm not sure what "in the name space of
> >>> the process that caused the core dump" means
> >
> > namespace is a concept from plan9. It basically means the tree
> > of mounts the current process has access to. On 99+% of the systems
> > that is only a single global tree, but there is support for processes
> > creating their own name space using clone CLONE_NEWNS and then
> > mount/umount/mount --bind etc. Linux VFS had this support for
> > some time.
> >
> > The whole thing is very obscure but perhaps some more
> > coverage in the man pages would be not bad. It seems to move
> > slowly out of obscurity now with all the new container work.
> >
> > There is some scattered information in Documentation/*. You'll need
> > someone else to explain you all the finer details though.
> >
> > Also there are lots of different mounts now since a few 2.6 kernels --
> > to be honest I don't understand what they are all good for.
> >
> >
> > -- I wondered if it might
> >>> mean that the current working directory of the program would be the
> >>> same as that of the process that caused the core dump.  However that
> >>> is not so: the current directory for the pipe program is the root
> >>> directory.
> >
> > Basically with a different namespace the paths can change completely,
> > which can in theory have some unpleasant effects on the core dumper
> > script. I skimped this by just always using the same as the process.
> >
> > -Andi
> >
> >
>
> --
> 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
>
>



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

Re: core_pattern pipe documentation

[Neil Horman]

On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> 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
> <mtk.manpages@googlemail.com> wrote:
> > 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
> >
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
 ***************************************************/

Re: core_pattern pipe documentation

[Michael Kerrisk]

Hi Neil,

On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > 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
> > <mtk.manpages@googlemail.com> wrote:
> > > 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
> > >
> 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

Thanks for pointing that out!  I'll note it in the page.

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

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
you show a specific case where it doesn't give the "right" value?

>          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

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

Re: core_pattern pipe documentation

[Neil Horman]

On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> Hi Neil,
> 
> On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > 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
> > > <mtk.manpages@googlemail.com> wrote:
> > > > 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
> > > >
> > 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
> 
> Thanks for pointing that out!  I'll note it in the page.
> 
> >          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.
> 
> 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
> you show a specific case where it doesn't give the "right" value?
> 
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
re-writing it.  Thanks for that.  You can scratch this.


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


> 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

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

Re: core_pattern pipe documentation

[Michael Kerrisk]

On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > Hi Neil,
> >
> > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > 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
> > > > <mtk.manpages@googlemail.com> wrote:
> > > > > 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
> > > > >
> > > 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
> >
> > Thanks for pointing that out!  I'll note it in the page.
> >
> > >          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.
> >
> > 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
> > you show a specific case where it doesn't give the "right" value?
> >
> 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
> re-writing it.  Thanks for that.  You can scratch this.
>
>
> > >          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
> >
> > 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.)
> >
> 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?

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

Re: core_pattern pipe documentation

[Neil Horman]

On Fri, Apr 25, 2008 at 08:13:21PM +0200, Michael Kerrisk wrote:
> On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > > Hi Neil,
> > >
> > > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > > 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
> > > > > <mtk.manpages@googlemail.com> wrote:
> > > > > > 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
> > > > > >
> > > > 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
> > >
> > > Thanks for pointing that out!  I'll note it in the page.
> > >
> > > >          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.
> > >
> > > 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
> > > you show a specific case where it doesn't give the "right" value?
> > >
> > 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
> > re-writing it.  Thanks for that.  You can scratch this.
> >
> >
> > > >          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
> > >
> > > 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.)
> > >
> > 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?
> 
> 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
 ****************************************************/

Re: core_pattern pipe documentation

[Michael Kerrisk]

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

On Fri, Apr 25, 2008 at 8:54 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Fri, Apr 25, 2008 at 08:13:21PM +0200, Michael Kerrisk wrote:
> > On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > > > Hi Neil,
> > > >
> > > > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > > > 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
> > > > > > <mtk.manpages@googlemail.com> wrote:
> > > > > > > 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
> > > > > > >
> > > > > 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
> > > >
> > > > Thanks for pointing that out!  I'll note it in the page.
> > > >
> > > > >          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.
> > > >
> > > > 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
> > > > you show a specific case where it doesn't give the "right" value?
> > > >
> > > 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
> > > re-writing it.  Thanks for that.  You can scratch this.
> > >
> > >
> > > > >          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
> > > >
> > > > 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.)
> > > >
> > > 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?
> >
> > 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
>  ****************************************************/
>



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

Re: core_pattern pipe documentation

[Michael Kerrisk]

On Fri, Apr 25, 2008 at 8:54 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Fri, Apr 25, 2008 at 08:13:21PM +0200, Michael Kerrisk wrote:
> > On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > > > Hi Neil,
> > > >
> > > > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > > > 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
> > > > > > <mtk.manpages@googlemail.com> wrote:
> > > > > > > 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
> > > > > > >
> > > > > 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
> > > >
> > > > Thanks for pointing that out!  I'll note it in the page.
> > > >
> > > > >          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.
> > > >
> > > > 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
> > > > you show a specific case where it doesn't give the "right" value?
> > > >
> > > 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
> > > re-writing it.  Thanks for that.  You can scratch this.
> > >
> > >
> > > > >          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
> > > >
> > > > 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.)
> > > >
> > > 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?
> >
> > 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.

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?

Re: core_pattern pipe documentation

[Neil Horman]

On Fri, Apr 25, 2008 at 10:05:35PM +0200, Michael Kerrisk wrote:
> On Fri, Apr 25, 2008 at 8:54 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Fri, Apr 25, 2008 at 08:13:21PM +0200, Michael Kerrisk wrote:
> > > On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > > > > Hi Neil,
> > > > >
> > > > > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > > >
> > > > > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > > > > 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
> > > > > > > <mtk.manpages@googlemail.com> wrote:
> > > > > > > > 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
> > > > > > > >
> > > > > > 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
> > > > >
> > > > > Thanks for pointing that out!  I'll note it in the page.
> > > > >
> > > > > >          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.
> > > > >
> > > > > 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
> > > > > you show a specific case where it doesn't give the "right" value?
> > > > >
> > > > 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
> > > > re-writing it.  Thanks for that.  You can scratch this.
> > > >
> > > >
> > > > > >          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
> > > > >
> > > > > 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.)
> > > > >
> > > > 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?
> > >
> > > 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.
> 
> 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
 ****************************************************/

Re: core_pattern pipe documentation

[Michael Kerrisk]

On Fri, Apr 25, 2008 at 10:18 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Fri, Apr 25, 2008 at 10:05:35PM +0200, Michael Kerrisk wrote:
> > On Fri, Apr 25, 2008 at 8:54 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Fri, Apr 25, 2008 at 08:13:21PM +0200, Michael Kerrisk wrote:
> > > > On Fri, Apr 25, 2008 at 6:22 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > On Fri, Apr 25, 2008 at 03:18:46PM +0200, Michael Kerrisk wrote:
> > > > > > Hi Neil,
> > > > > >
> > > > > > On Wed, Apr 23, 2008 at 4:59 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > > > >
> > > > > > > On Wed, Apr 23, 2008 at 02:09:14PM +0200, Michael Kerrisk wrote:
> > > > > > > > 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
> > > > > > > > <mtk.manpages@googlemail.com> wrote:
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > 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
> > > > > >
> > > > > > Thanks for pointing that out!  I'll note it in the page.
> > > > > >
> > > > > > >          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.
> > > > > >
> > > > > > 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
> > > > > > you show a specific case where it doesn't give the "right" value?
> > > > > >
> > > > > 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
> > > > > re-writing it.  Thanks for that.  You can scratch this.
> > > > >
> > > > >
> > > > > > >          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
> > > > > >
> > > > > > 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.)
> > > > > >
> > > > > 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?
> > > >
> > > > 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.
> >
> > 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

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

core_pattern pipe documentation - draft 2

[Michael Kerrisk]

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 the program.  Note the following points:

       *  The program must be specified using an absolute pathname (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.

       *  Command-line arguments can be supplied to the program (since
          kernel 2.6.24), delimited by white space (up to a total line
          length of 128 bytes).

       *  The command-line arguments can include any of the  %  speci-
          fiers  listed  above.   For  example, to pass the PID of the
          process that is being dumped, specify %p in an argument.

   [...]
   EXAMPLE
       The  program  below  can  be used to demonstrate the use of the
       pipe syntax in  the  /proc/sys/kernel/core_pattern  file.   The
       following  shell  session  demonstrates the use of this program
       (compiled to create an executable named core_pattern_test):

           $ cc -o core_pattern_test core_pattern_test.c
           $ su
           Password:
           # echo "|$PWD/core_pattern_test %p UID=%u GID=%g sig=%s" > \
               /proc/sys/kernel/core_pattern
           # exit
           $ sleep 100
           type control-backslash
           Quit (core dumped)
           $ cat core.info
           argc=5
           argc[0]=</home/mtk/core_pattern_test>
           argc[1]=<20575>
           argc[2]=<UID=1000>
           argc[3]=<GID=100>
           argc[4]=<sig=3>
           Total bytes in core dump: 282624

       The source code of the program is as follows:

       /* core_pattern_test.c */

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

       #define BUF_SIZE 1024

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

           /* Change our current working directory to that of the
              crashing process */

           snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
           chdir(cwd);

           /* Write output to file "core.info" in that directory */

           fp = fopen("core.info", "w+");
           if (fp == NULL)
               exit(EXIT_FAILURE);

           /* Display command-line arguments given to core_pattern
              pipe program */

           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 (the core dump) */

           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);
       }

Re: core_pattern pipe documentation - draft 2

[Neil Horman]

On Mon, May 05, 2008 at 09:19:16AM +0200, Michael Kerrisk wrote:
> 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 the program.  Note the following points:
> 
>        *  The program must be specified using an absolute pathname (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.
> 
>        *  Command-line arguments can be supplied to the program (since
>           kernel 2.6.24), delimited by white space (up to a total line
>           length of 128 bytes).
> 
>        *  The command-line arguments can include any of the  %  speci-
>           fiers  listed  above.   For  example, to pass the PID of the
>           process that is being dumped, specify %p in an argument.
> 
>    [...]
>    EXAMPLE
>        The  program  below  can  be used to demonstrate the use of the
>        pipe syntax in  the  /proc/sys/kernel/core_pattern  file.   The
>        following  shell  session  demonstrates the use of this program
>        (compiled to create an executable named core_pattern_test):
> 
>            $ cc -o core_pattern_test core_pattern_test.c
>            $ su
>            Password:
>            # echo "|$PWD/core_pattern_test %p UID=%u GID=%g sig=%s" > \
>                /proc/sys/kernel/core_pattern
>            # exit
>            $ sleep 100
>            type control-backslash
>            Quit (core dumped)
>            $ cat core.info
>            argc=5
>            argc[0]=</home/mtk/core_pattern_test>
>            argc[1]=<20575>
>            argc[2]=<UID=1000>
>            argc[3]=<GID=100>
>            argc[4]=<sig=3>
>            Total bytes in core dump: 282624
> 
>        The source code of the program is as follows:
> 
>        /* core_pattern_test.c */
> 
>        #define _GNU_SOURCE
>        #include <sys/stat.h>
>        #include <fcntl.h>
>        #include <limits.h>
>        #include <stdio.h>
>        #include <stdlib.h>
>        #include <unistd.h>
> 
>        #define BUF_SIZE 1024
> 
>        int
>        main(int argc, char *argv[])
>        {
>            int tot, j;
>            ssize_t nread;
>            char buf[BUF_SIZE];
>            FILE *fp;
>            char cwd[PATH_MAX];
> 
>            /* Change our current working directory to that of the
>               crashing process */
> 
>            snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
>            chdir(cwd);
> 
>            /* Write output to file "core.info" in that directory */
> 
>            fp = fopen("core.info", "w+");
>            if (fp == NULL)
>                exit(EXIT_FAILURE);
> 
>            /* Display command-line arguments given to core_pattern
>               pipe program */
> 
>            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 (the core dump) */
> 
>            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);
>        }

All looks great to me, thanks!

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


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