From owner-freebsd-questions@freebsd.org Wed Aug 12 17:03:47 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73B163A6528 for ; Wed, 12 Aug 2020 17:03:47 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4BRbdG2SvYz49bX for ; Wed, 12 Aug 2020 17:03:45 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id 294404E746; Wed, 12 Aug 2020 10:03:44 -0700 (PDT) From: "Ronald F. Guilmette" To: Polytropon cc: Yasuhiro KIMURA , freebsd-questions@freebsd.org Subject: Re: GDB no workie? Permission problem? In-Reply-To: <20200812165931.702fd7ea.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72828.1597251823.1@segfault.tristatelogic.com> Date: Wed, 12 Aug 2020 10:03:44 -0700 Message-ID: <72829.1597251824@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 4BRbdG2SvYz49bX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-1.31 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.042]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-0.95)[-0.950]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.02)[-0.017]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 17:03:47 -0000 In message <20200812165931.702fd7ea.freebsd@edvax.de>, you wrote: >On Tue, 11 Aug 2020 23:37:07 -0700, Ronald F. Guilmette wrote: >> Thank you. The code seems to suggets that I just need to edit a >> file called $BSDINSTALL_TMPBOOT/loader.conf.hardening but I will be >> damned if I can find any such on my system, anywhere in my root >> partition. So I'm stumped. > >You need to edit the _Actual_ loader configuration file, >which is /boot/loader.conf; Ahhhhh! OK. Done! Thank you. >also have a look at the sysctl >control file, /etc/sysctl.conf, as mentioned in my previous >message - which did only arrive at the list, but not in your >mailbox, as your ISP seems to block 1&1, Germany's probably >most important ISP. 1&1 may be "important" but it is also a consistant source of spam and does not respond in any manner that I would judge to be "appropriate" to notifications regarding spam from their network. Thus, they have been blocked locally. >> To make matters even worse, the >> output I get from "sysctl -a" doesn't even seem to list -any- >> sysctl variable called "security.bsd.allow_destructive_dtrace", so >> I am double stumped. > >Because it's not a DTrace problem - it's probably something >else. Check > > % sysctl -a | grep security > >for all security-related variables; I'm sure you find one or >two that deviate from the default setting. Well, this is very odd indeed. In my /boot/loader.conf I did indeed find a line that said: security.bsd.allow_destructive_dtrace=0 (which I have now edited) however this command: sysctl -a | grep security.bsd yields only: security.bsd.stack_guard_page: 1 security.bsd.unprivileged_get_quota: 0 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_idprio: 0 security.bsd.unprivileged_proc_debug: 0 security.bsd.conservative_signals: 1 security.bsd.see_jail_proc: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 0 security.bsd.unprivileged_mlock: 1 security.bsd.suser_enabled: 1 security.bsd.map_at_zero: 0 It seems apparent to me that security.bsd.unprivileged_proc_debug is the sysctl variable of interest here, however I am still mystified as to why changinging the value of: security.bsd.allow_destructive_dtrace (via the /boot/loader.conf file) would affect this different named variable, security.bsd.unprivileged_proc_debug. I can only guess that it this must be due to some sort of backward compatability magic that I am not aware of. In any case, I need to reboot now and see if my edit to my /boot/loader.conf file has accomplished the change I desire. Regards, rfg