Message ID | 1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 91049 invoked by alias); 18 Sep 2017 18:44:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 91018 invoked by uid 89); 18 Sep 2017 18:44:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:2246 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Sep 2017 18:44:00 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8IIddW3036130 for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 14:43:59 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2d2dakr8pn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 14:43:59 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Mon, 18 Sep 2017 19:43:57 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 18 Sep 2017 19:43:56 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v8IIht7020709502 for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 18:43:55 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2DB7A4053 for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 19:39:58 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8A63A404D for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 19:39:58 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.164]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP for <gdb-patches@sourceware.org>; Mon, 18 Sep 2017 19:39:58 +0100 (BST) From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: gdb-patches@sourceware.org Subject: [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump Date: Mon, 18 Sep 2017 20:41:52 +0200 In-Reply-To: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> References: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 17091818-0040-0000-0000-000003DADC95 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17091818-0041-0000-0000-000025DC095C Message-Id: <1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709180264 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
Sept. 18, 2017, 6:41 p.m. UTC
So far the test suite skips tests if they need system-generated core files and the core files can not be found. In particular this is usually the case on systems with an active systemd-coredump service. On such systems, core files are not written into the local directory, but made accessible via a command-line utitily "coredumpctl" instead. This patch enables processing core files on such systems as well. Note that there are a few quirks: * In my tests, after invoking a command that dumps core, it could happen that "coredumpctl" did not find the dump immediately afterwards. After waiting a bit, the dump was found and could be accessed. Thus the patch performs a single wait-and-retry in case of failure. * There does not seem to be a way for a user to remove specific core dumps from the journal. Thus it can happen that "coredumpctl" returns an old dump, and the test case continues with that instead of the new one. It might be possible to improve the logic here, by considering the time stamps as well. I leave that for a future patch. * On the system I've tested it on, the bigcore.exp test case still failed because coredumpctl truncated the core file after 4G for some reason. gdb/testsuite/ChangeLog: * lib/gdb.exp (find_core): Add handling for targets with systemd-coredump, using the coredumpctl command. --- gdb/testsuite/lib/gdb.exp | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Comments
On 09/18/2017 07:41 PM, Andreas Arnez wrote: > So far the test suite skips tests if they need system-generated core files > and the core files can not be found. In particular this is usually the > case on systems with an active systemd-coredump service. On such systems, > core files are not written into the local directory, but made accessible > via a command-line utitily "coredumpctl" instead. > > This patch enables processing core files on such systems as well. Note > that there are a few quirks: > > * In my tests, after invoking a command that dumps core, it could happen > that "coredumpctl" did not find the dump immediately afterwards. After > waiting a bit, the dump was found and could be accessed. Thus the patch > performs a single wait-and-retry in case of failure. > > * There does not seem to be a way for a user to remove specific core dumps > from the journal. Thus it can happen that "coredumpctl" returns an old > dump, and the test case continues with that instead of the new one. It > might be possible to improve the logic here, by considering the time > stamps as well. I leave that for a future patch. > > * On the system I've tested it on, the bigcore.exp test case still failed > because coredumpctl truncated the core file after 4G for some reason. I'm a bit unsure about whether this is the right approach, expecially given the caveats above. Also, this seems to mean that running the testsuite on such a system clutters the system log on and on, maybe even triggers dispatch of notifications to admins, etc. I wonder whether there's a way to tell systemd-coredump to let the core dumps be generated on the file system for the current shell environment? Like we try to run "ulimit -c unlimited". Failing that, it may be better to instead make the testsuite skip the tests gracefully, and display a big and visible warning if systemd-coredump is detected as active. I mean, you already have to tweak other things in the system in order to be able to run the testsuite correctly. For example, you have to tweak /proc/sys/kernel/yama/ptrace_scope to make attach tests work at all, for example. systemd-coredump kind of seems like more of the same. Dunno, as I said, I'm unsure. Thanks, Pedro Alves
On Tue, Oct 17 2017, Pedro Alves wrote: > On 09/18/2017 07:41 PM, Andreas Arnez wrote: >> So far the test suite skips tests if they need system-generated core files >> and the core files can not be found. In particular this is usually the >> case on systems with an active systemd-coredump service. On such systems, >> core files are not written into the local directory, but made accessible >> via a command-line utitily "coredumpctl" instead. >> >> This patch enables processing core files on such systems as well. Note >> that there are a few quirks: >> >> * In my tests, after invoking a command that dumps core, it could happen >> that "coredumpctl" did not find the dump immediately afterwards. After >> waiting a bit, the dump was found and could be accessed. Thus the patch >> performs a single wait-and-retry in case of failure. >> >> * There does not seem to be a way for a user to remove specific core dumps >> from the journal. Thus it can happen that "coredumpctl" returns an old >> dump, and the test case continues with that instead of the new one. It >> might be possible to improve the logic here, by considering the time >> stamps as well. I leave that for a future patch. >> >> * On the system I've tested it on, the bigcore.exp test case still failed >> because coredumpctl truncated the core file after 4G for some reason. > > I'm a bit unsure about whether this is the right approach, > expecially given the caveats above. Also, this seems to mean that > running the testsuite on such a system clutters the system log on and on, > maybe even triggers dispatch of notifications to admins, etc. The caveats above are really bugs/design flaws of systemd-coredump. If nothing else, maybe this discussion helps addressing them. Offering no way to prevent system log cluttering could be viewed as another flaw, see also below. > I wonder whether there's a way to tell systemd-coredump to > let the core dumps be generated on the file system for the current > shell environment? Like we try to run "ulimit -c unlimited". I agree that there *should* be such a way -- but I haven't found any. And such a mechanism should probably allow suppressing the log entries as well. > Failing that, it may be better to instead make the testsuite skip > the tests gracefully, and display a big and visible warning > if systemd-coredump is detected as active. This might be the right trade-off if we expect test cases to be executed only on systems that the user has full control over. But I consider this restriction too tight and would prefer a "best effort" approach instead. Maybe we should emit a warning *and* try our best to execute the test? > I mean, you already have to tweak other things in the system in > order to be able to run the testsuite correctly. For example, > you have to tweak /proc/sys/kernel/yama/ptrace_scope to make > attach tests work at all, for example. systemd-coredump kind of > seems like more of the same. So should we document a sequence of admin commands that makes a system debug-ready, or in particular ready for the GDB test suite? But I'm not so sure about this. IMHO a default mainstream Linux installation should be suited for development- and debugging purposes *without* any tweaking. Also, if there are good reasons for a security measure, we shouldn't rely on disabling it globally. With respect to Yama's ptrace scope, the distributions seem to differ. For instance, Fedora does not activate it by default (https://fedoraproject.org/wiki/Security_Features_Matrix), while Ubuntu does (https://wiki.ubuntu.com/Security/Features). And I wonder whether this feature couldn't be adjusted to be more debug-friendly either. -- Andreas
On 10/17/2017 06:36 PM, Andreas Arnez wrote: > On Tue, Oct 17 2017, Pedro Alves wrote: > >> On 09/18/2017 07:41 PM, Andreas Arnez wrote: >>> So far the test suite skips tests if they need system-generated core files >>> and the core files can not be found. In particular this is usually the >>> case on systems with an active systemd-coredump service. On such systems, >>> core files are not written into the local directory, but made accessible >>> via a command-line utitily "coredumpctl" instead. >>> >>> This patch enables processing core files on such systems as well. Note >>> that there are a few quirks: >>> >>> * In my tests, after invoking a command that dumps core, it could happen >>> that "coredumpctl" did not find the dump immediately afterwards. After >>> waiting a bit, the dump was found and could be accessed. Thus the patch >>> performs a single wait-and-retry in case of failure. >>> >>> * There does not seem to be a way for a user to remove specific core dumps >>> from the journal. Thus it can happen that "coredumpctl" returns an old >>> dump, and the test case continues with that instead of the new one. It >>> might be possible to improve the logic here, by considering the time >>> stamps as well. I leave that for a future patch. >>> >>> * On the system I've tested it on, the bigcore.exp test case still failed >>> because coredumpctl truncated the core file after 4G for some reason. >> >> I'm a bit unsure about whether this is the right approach, >> expecially given the caveats above. Also, this seems to mean that >> running the testsuite on such a system clutters the system log on and on, >> maybe even triggers dispatch of notifications to admins, etc. > > The caveats above are really bugs/design flaws of systemd-coredump. If > nothing else, maybe this discussion helps addressing them. Offering no > way to prevent system log cluttering could be viewed as another flaw, > see also below. > >> I wonder whether there's a way to tell systemd-coredump to >> let the core dumps be generated on the file system for the current >> shell environment? Like we try to run "ulimit -c unlimited". > > I agree that there *should* be such a way -- but I haven't found any. > And such a mechanism should probably allow suppressing the log entries > as well. > >> Failing that, it may be better to instead make the testsuite skip >> the tests gracefully, and display a big and visible warning >> if systemd-coredump is detected as active. > > This might be the right trade-off if we expect test cases to be executed > only on systems that the user has full control over. But I consider > this restriction too tight and would prefer a "best effort" approach > instead. Maybe we should emit a warning *and* try our best to execute > the test? Not sure, really. It seems like the "best effort" results in racy tests, e.g., if "coredumpctl" returns an old dump, or if coredumpctl decides to rate-limit core dump generation (which according to the docs, it does). It very much sounds like that can lead to hard to diagnose problems and send GDB hackers tilting at windmills. > >> I mean, you already have to tweak other things in the system in >> order to be able to run the testsuite correctly. For example, >> you have to tweak /proc/sys/kernel/yama/ptrace_scope to make >> attach tests work at all, for example. systemd-coredump kind of >> seems like more of the same. > > So should we document a sequence of admin commands that makes a system > debug-ready, or in particular ready for the GDB test suite? IMO, yes. We already have something like that, but it's mixed with the instructions for setting up builders: https://sourceware.org/gdb/wiki/BuildBot#Fedora-specific_instructions (Note we already suggest disabling ABRT and tweaking kernel.core_pattern.) It'd be great to move that info to some specific page about setting up an environment for developing and testing GDB. Also, some of the command sequences there could move to scripts under gdb/contrib/, IMHO. > > But I'm not so sure about this. IMHO a default mainstream Linux > installation should be suited for development- and debugging purposes > *without* any tweaking. Also, if there are good reasons for a security > measure, we shouldn't rely on disabling it globally. I think that battle is lost. Mainstream Linux installations are already very much not suited for development OOTB. You have to install a bunch of development packages that are not installed by default, before you can build anything, including compiler, etc. If you can install packages, then you can also disable a few features that really are not meant for development environments. What we're missing is a simple "one-click button" way to adapt an installation / user environment for development. > > With respect to Yama's ptrace scope, the distributions seem to differ. > For instance, Fedora does not activate it by default > (https://fedoraproject.org/wiki/Security_Features_Matrix), while Ubuntu > does (https://wiki.ubuntu.com/Security/Features). And I wonder whether > this feature couldn't be adjusted to be more debug-friendly either. The whole point of the feature is to prevent debugging, so I don't see how, off hand. Note that on Fedora nowadays, if you install GDB, then Yama's ptrace scope is relaxed via a rpm package dependency. systemd-coredump could also be treated in the same way -- disable it for users that have GDB or other development tools installed. I don't actually know whether it's possible to disable systemd-coredump for a single user, though it seems to me like an obviously desirable feature. Thanks, Pedro Alves
On 10/17/2017 07:08 PM, Pedro Alves wrote: > Not sure, really. It seems like the "best effort" results in > racy tests, e.g., if "coredumpctl" returns an old dump, or > if coredumpctl decides to rate-limit core dump generation (which > according to the docs, it does). It very much sounds like that > can lead to hard to diagnose problems and send GDB hackers tilting > at windmills. I should add that I won't oppose this too strongly _if_ we make the warning not easily lost in the noise, like e.g., maybe tacked to the end of all test runs, near the final test results summary? Thanks, Pedro Alves
On 10/17/2017 07:14 PM, Pedro Alves wrote: > On 10/17/2017 07:08 PM, Pedro Alves wrote: > >> Not sure, really. It seems like the "best effort" results in >> racy tests, e.g., if "coredumpctl" returns an old dump, or >> if coredumpctl decides to rate-limit core dump generation (which >> according to the docs, it does). It very much sounds like that >> can lead to hard to diagnose problems and send GDB hackers tilting >> at windmills. > > I should add that I won't oppose this too strongly _if_ we make > the warning not easily lost in the noise, like e.g., maybe tacked > to the end of all test runs, near the final test results summary? Another approach would be to not run the core tests by default, unless you specify some make check \ RUNTESTFLAGS="YES_I_KNOW_ALL_ABOUT_SYSTEMD_COREDUMP_RUN_THE_TESTS_ANYWAY_MKAY=1" option. (and then the testsuite would print a warning suggesting that.) Thanks, Pedro Alves
On Tue, Oct 17 2017, Pedro Alves wrote: > On 10/17/2017 06:36 PM, Andreas Arnez wrote: [...] >> This might be the right trade-off if we expect test cases to be executed >> only on systems that the user has full control over. But I consider >> this restriction too tight and would prefer a "best effort" approach >> instead. Maybe we should emit a warning *and* try our best to execute >> the test? > > Not sure, really. It seems like the "best effort" results in > racy tests, e.g., if "coredumpctl" returns an old dump, or > if coredumpctl decides to rate-limit core dump generation (which > according to the docs, it does). It very much sounds like that > can lead to hard to diagnose problems and send GDB hackers tilting > at windmills. That might be. However, the same problems may affect *any* coredumpctl user, not just the GDB test suite. And coredumpctl users are *our* users, after all. Maybe we should postpone GDB test suite support for systemd-coredump until these problems are fixed. But if all "informed developers" just give up and disable systemd-coredump, I fear that they will never be addressed. > >> >>> I mean, you already have to tweak other things in the system in >>> order to be able to run the testsuite correctly. For example, >>> you have to tweak /proc/sys/kernel/yama/ptrace_scope to make >>> attach tests work at all, for example. systemd-coredump kind of >>> seems like more of the same. >> >> So should we document a sequence of admin commands that makes a system >> debug-ready, or in particular ready for the GDB test suite? > > IMO, yes. We already have something like that, but it's mixed with > the instructions for setting up builders: > > https://sourceware.org/gdb/wiki/BuildBot#Fedora-specific_instructions > > (Note we already suggest disabling ABRT and tweaking > kernel.core_pattern.) > > It'd be great to move that info to some specific page about setting > up an environment for developing and testing GDB. Also, some of > the command sequences there could move to scripts under gdb/contrib/, > IMHO. Yeah, that would be good. > >> >> But I'm not so sure about this. IMHO a default mainstream Linux >> installation should be suited for development- and debugging purposes >> *without* any tweaking. Also, if there are good reasons for a security >> measure, we shouldn't rely on disabling it globally. > > I think that battle is lost. That surely sounds depressing... I guess I'm late to the battlefield then ;-) > Mainstream Linux installations are already very much not suited for > development OOTB. You have to install a bunch of development packages > that are not installed by default, before you can build anything, > including compiler, etc. If you can install packages, then you can > also disable a few features that really are not meant for development > environments. What we're missing is a simple "one-click button" way > to adapt an installation / user environment for development. Let me just point out that I see a difference between installing additional packages and disabling security measures. Admins might be easily convinced to do the former, but there will probably be more push back on the latter. A "one-click button" would not really help with that. And all this sounds as if developers were no longer seen as a target group of a Fedora distribution, say. On the other hand -- quote --: "Fedora Workstation is a polished, easy to use operating system for laptop and desktop computers, with a complete set of tools for developers and makers of all kinds." > >> >> With respect to Yama's ptrace scope, the distributions seem to differ. >> For instance, Fedora does not activate it by default >> (https://fedoraproject.org/wiki/Security_Features_Matrix), while Ubuntu >> does (https://wiki.ubuntu.com/Security/Features). And I wonder whether >> this feature couldn't be adjusted to be more debug-friendly either. > > The whole point of the feature is to prevent debugging, so I don't > see how, off hand. Well, I think the goal is to prevent visibility of sensitive data like passwords and keys through ptrace -- which is a fair point. But does this really require disabling ptrace from "non-ancestor" processes completely? It just seems to me that the collateral damage to debug capabilities was accepted too easily in this design. [...] Anyway, regarding GDB test suite support for systemd-coredump, I won't push too hard. While I have a slight preference towards "best effort", I understand your concern with possible surprises. So I'm fine with dropping this patch. Patch #1 in this series might still be useful, so I'll send an updated version of it. -- Andreas
On 10/18/2017 04:56 PM, Andreas Arnez wrote: > On Tue, Oct 17 2017, Pedro Alves wrote: > >> On 10/17/2017 06:36 PM, Andreas Arnez wrote: > > [...] > >>> This might be the right trade-off if we expect test cases to be executed >>> only on systems that the user has full control over. But I consider >>> this restriction too tight and would prefer a "best effort" approach >>> instead. Maybe we should emit a warning *and* try our best to execute >>> the test? >> >> Not sure, really. It seems like the "best effort" results in >> racy tests, e.g., if "coredumpctl" returns an old dump, or >> if coredumpctl decides to rate-limit core dump generation (which >> according to the docs, it does). It very much sounds like that >> can lead to hard to diagnose problems and send GDB hackers tilting >> at windmills. > > That might be. However, the same problems may affect *any* coredumpctl > user, not just the GDB test suite. And coredumpctl users are *our* > users, after all. Sure, but we're not interested in testing coredumpctl's ability to copy a core dump out of the log before that file is handed over to gdb? We're testing GDB's ability to load a core dump file that the kernel produced, doesn't matter to us really how many hoops the file went through before it was fed to gdb. I mean, we don't go and run filesystem-level stress-tests because we copy files around in the filesystem -- we just assume the filesystem is bug free, and let filesystem folks worry about such testing. If coredumpctl Just Worked flawlessly for our testsuite's use case (which is not like a regular user's use case), then I'd be all for this. My problem is really that it doesn't really work all that well, and by not informing GDB developers that there's (currently...) a better non-racy way to run make-sure-you-can-load-kernel-core-dumps tests, then we're not doing our follow GDB developers a real service. > Maybe we should postpone GDB test suite support for > systemd-coredump until these problems are fixed. But if all "informed > developers" just give up and disable systemd-coredump, I fear that they > will never be addressed. Judging from our rate of fixes for our own racy-tests, some of which are caused by other-components issues (frequently glibc/kernel), I don't think that exposing us to more sources of races will help with that either. >>> But I'm not so sure about this. IMHO a default mainstream Linux >>> installation should be suited for development- and debugging purposes >>> *without* any tweaking. Also, if there are good reasons for a security >>> measure, we shouldn't rely on disabling it globally. >> >> I think that battle is lost. > > That surely sounds depressing... I guess I'm late to the battlefield > then ;-) My remark may have sounded fatalistic, but in reality nothing is ever settled forever in software land. All it really takes is someone motivated to go and improve things, work with the relevant communities, etc. It's just that it's an uphill battle, where there seems to be a lot more interest/investment in the community to make things secure by default even if it makes it a little more inconvenient for the system component developer. Balancing both a bit better might be possible, but it requires commitment, involvement and a vigilant eye over the whole stack. History is showing that this just won't come "for free" for us, unfortunately. Let's also not forget that the needs of a GDB developer are not the same as the needs of a developer that uses GDB to debug its own programs for a given system. GDB _is_ part of the system, and regression testing it involves stressing other system components in ways that a normal developer normally won't. For example, running the testsuite could in theory well end up producing hundreds of core dumps for a variation of tests in a few seconds. A regular developer doesn't need that. Another example, ideally, we'd have tests that make sure that GDB behaves correctly when Yama rejects an attach, when it rejects spawning a child process, _in addition_ to testing actual run and attach succeeding. So ideally we'd have a way to control the Yama scope at run time without affecting the whole system. But that's something that you can't do unless you're root, and running the testsuite with root permissions is not something that I'd recommend (though maybe we could have an optional "testsuite/gdb.root/" directory with such tests). > >> Mainstream Linux installations are already very much not suited for >> development OOTB. You have to install a bunch of development packages >> that are not installed by default, before you can build anything, >> including compiler, etc. If you can install packages, then you can >> also disable a few features that really are not meant for development >> environments. What we're missing is a simple "one-click button" way >> to adapt an installation / user environment for development. > > Let me just point out that I see a difference between installing > additional packages and disabling security measures. Admins might be > easily convinced to do the former, but there will probably be more push > back on the latter. A "one-click button" would not really help with > that. > > And all this sounds as if developers were no longer seen as a target > group of a Fedora distribution, say. On the other hand -- quote --: > "Fedora Workstation is a polished, easy to use operating system for > laptop and desktop computers, with a complete set of tools for > developers and makers of all kinds." > >> >>> >>> With respect to Yama's ptrace scope, the distributions seem to differ. >>> For instance, Fedora does not activate it by default >>> (https://fedoraproject.org/wiki/Security_Features_Matrix), while Ubuntu >>> does (https://wiki.ubuntu.com/Security/Features). And I wonder whether >>> this feature couldn't be adjusted to be more debug-friendly either. >> >> The whole point of the feature is to prevent debugging, so I don't >> see how, off hand. > > Well, I think the goal is to prevent visibility of sensitive data like > passwords and keys through ptrace -- which is a fair point. But does > this really require disabling ptrace from "non-ancestor" processes > completely? It just seems to me that the collateral damage to debug > capabilities was accepted too easily in this design. > > [...] > > Anyway, regarding GDB test suite support for systemd-coredump, I won't > push too hard. While I have a slight preference towards "best effort", > I understand your concern with possible surprises. So I'm fine with > dropping this patch. (Again, I don't mind this going in if we make it visibly warn/optional.) > Patch #1 in this series might still be useful, so > I'll send an updated version of it. Yes, please. Thanks!
On Thu, Oct 19 2017, Pedro Alves wrote: [...] > If coredumpctl Just Worked flawlessly for our testsuite's use > case (which is not like a regular user's use case), then I'd be all > for this. My problem is really that it doesn't really work > all that well, [...] FWIW, to help the GDB test suite (and others) in the future, I've opened a systemd feature request to support switching to "classical" core dump behavior for certain programs: https://github.com/systemd/systemd/issues/7166 Anyone interested, feel free to subscribe. -- Andreas
On 10/23/2017 02:41 PM, Andreas Arnez wrote: > On Thu, Oct 19 2017, Pedro Alves wrote: > > [...] > >> If coredumpctl Just Worked flawlessly for our testsuite's use >> case (which is not like a regular user's use case), then I'd be all >> for this. My problem is really that it doesn't really work >> all that well, [...] > > FWIW, to help the GDB test suite (and others) in the future, I've opened > a systemd feature request to support switching to "classical" core dump > behavior for certain programs: > > https://github.com/systemd/systemd/issues/7166 > > Anyone interested, feel free to subscribe. Excellent, thanks much! I've subscribed. Pedro Alves
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 1fd0009..7f80e12 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -5877,6 +5877,19 @@ proc find_core {binfile coredir {destcore ""}} { } } + # We may be running on a system with the systemd-coredump service in + # effect; try the coredumpctl command. But due to asynchronous + # processing the core dump may not have been processed yet. Thus wait + # a bit and retry after failure. + foreach delay {0 1} { + sleep $delay + if {![catch {exec -ignorestderr coredumpctl -o $destcore dump $binfile}]} { + if [file exists $destcore] { + return $destcore + } + } + } + warning "Can not locate core dump generated by \"[file tail $binfile]\"." return "" }