| 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
| ||
|
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/
Powered by blists - more mailing lists