GDB no workie? Permission problem?

[Ronald F. Guilmette]

In message <20200812165931.702fd7ea.freebsd at 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