linux-kernel - Re: core_pattern pipe documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080425162225.GA9833@hmsreliant.think-freely.org>
Date:	Fri, 25 Apr 2008 12:22:25 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-man@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Petr Gajdos <pgajdos@...e.cz>, michael.kerrisk@...il.com
Subject: Re: core_pattern pipe documentation

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@...driver.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@...glemail.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@...driver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/