Thread: Re: debugger from superuser only.... why?

On Wed, Sep 20, 2023 at 9:32 AM Александр Петросян (web) <paf@yandex.ru> wrote:
>
> Checked few sources, can not seem to find reasoning behind this limit:
>
> > You must have superuser privileges to use the debugger.
>

It means database superuser.

> What is the reason?

I suspect the debugger will need to open a connection back to pgadmin,
and that probably is the need for privileges.

Luca

SELECT * FROM pldbg_set_global_breakpoint(1, 65695, -1, NULL);

SELECT setting

FROM pg_settings

WHERE name = 'shared_preload_libraries';

SELECT * FROM (SELECT

                   t_namespace.nspname,

                   t_extension.extname,

                   t_extension.extversion

               FROM pg_extension t_extension

                        JOIN pg_namespace t_namespace ON t_extension.extnamespace = t_namespace.oid)q;

SELECT * FROM (SELECT pid,

                      application_name,

                      usename,

                      client_addr

               FROM pg_stat_activity

               WHERE application_name = 'idea_debugger'

                 AND pid <> pg_backend_pid())q;

SELECT * FROM pldbg_create_listener();

On Fri, Sep 22, 2023 at 1:28 PM Alexander Petrossian
<alexander.petrossian@gmail.com> wrote:
> SELECT * FROM pldbg_set_global_breakpoint(1, 65695, -1, NULL);
>
> ERROR: must be a superuser to create a breakpoint
>
>
> I am wondering why is this, why not allow debugging for non-privileged users?

Again, I'm suspecting that this debugger works by performing a
sandboxing and attaching your session back. In order to communicate
back and forth, you probably need such privileges.
You should ask the developers why they need such privileges, or dig
the code by yourself.



> SELECT setting
> FROM pg_settings
> WHERE name = 'shared_preload_libraries';
>

nothing to debug at all in here

> SELECT * FROM (SELECT
>                    t_namespace.nspname,
>                    t_extension.extname,
>                    t_extension.extversion
>                FROM pg_extension t_extension
>                         JOIN pg_namespace t_namespace ON t_extension.extnamespace = t_namespace.oid)q;
>

ditto

> SELECT * FROM (SELECT pid,
>                       application_name,
>                       usename,
>                       client_addr
>                FROM pg_stat_activity
>                WHERE application_name = 'idea_debugger'
>                  AND pid <> pg_backend_pid())q;

nothing to debug in here


> SELECT * FROM pldbg_create_listener();

uh oh, it mentions a listener...then there must be some "sender"
somehwere, that probably needs privileges.

Luca

On Fri, Sep 22, 2023 at 2:00 PM Alexander Petrossian (PAF)
<alexander.petrossian@gmail.com> wrote:
> Some mail list you would suggest, Luka?
>

pgadmin mailing list, or ask EDB somehwere.

>>
>> > SELECT * FROM pldbg_create_listener();
>> uh oh, it mentions a listener...then there must be some "sender"
>> somehwere, that probably needs privileges.
>
>
> Surprisingly this passes OK under non-privileged user.

I meant: somewhere else there must be something that connects back and
requires privileges.

Also, this (not tried) does not seem to require other privileges
<https://github.com/OmniDB/plpgsql_debugger>.

Luca

hi,
the first steps to use debugger:
1. modify config file
2. restart server
...
i would say, enough reasons to be superuser or not?

On Fri, Sep 22, 2023 at 9:05 PM <postgresql439848@heinz-it.de> wrote:
>
> hi,
> the first steps to use debugger:
> 1. modify config file
> 2. restart server
> ...
> i would say, enough reasons to be superuser or not?

Well, the above are not privileges "to use" the debugger, rather "to
configure" the debugger.

Luca

>
>

Alexander Petrossian <alexander.petrossian@gmail.com> writes:
>>> I am wondering why is this, why not allow debugging for non-privileged users?

Seems obvious to me that it'd be a nasty security hole, ie you could
take control of somebody else's session and make it do things you
don't have permissions for.  Even if there's a way to restrict
debugging connections to sessions owned by the same user, you'd
have a big problem with being able to change the behavior of
security-definer functions.  Clearly, the authors of pldebugger
decided that was a can of worms they didn't care to open.

            regards, tom lane

> 25 сент. 2023 г., в 17:28, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
> Alexander Petrossian <alexander.petrossian@gmail.com> writes:
>>>> I am wondering why is this, why not allow debugging for non-privileged users?
> Even if there's a way to restrict
> debugging connections to sessions owned by the same user,

I guess, there is such a way. Looks trivial...

> you’d have a big problem with being able to change the behavior of
> security-definer functions.

Could you please elaborate on this, Tom?

My worry is that it is very inconvenient.
And if reasons are not super-solid, maybe one can budge the Author? :)

>  Clearly, the authors of pldebugger
> decided that was a can of worms they didn't care to open.

Unless one wants to go fishing ;)

PAF

Alexander Petrossian <alexander.petrossian@gmail.com> writes:
> 25 сент. 2023 г., в 17:28, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
>> you’d have a big problem with being able to change the behavior of
>> security-definer functions.

> Could you please elaborate on this, Tom?

pldebugger allows you to change the contents of a function's
local variables.  Obviously the threat level would depend a lot
on the details of the particular function, but it's not hard
to envision cases where that would be enough to make the function
do something other than what it was supposed to.

            regards, tom lane

On Wed, Sep 27, 2023 at 1:30 PM Alexander Petrossian
<alexander.petrossian@gmail.com> wrote:
>
> > 25 сент. 2023 г., в 17:28, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
> > Alexander Petrossian <alexander.petrossian@gmail.com> writes:
> >>>> I am wondering why is this, why not allow debugging for non-privileged users?
> > Even if there's a way to restrict
> > debugging connections to sessions owned by the same user,
>
> I guess, there is such a way. Looks trivial...
>


I think that any debugger in any environment can be nasty things,
being able to trace and modify a running "thing". Having said that, I
believe that the reason about why pldebugger needs superuser
privileges could be explained only by the authors (or someone reading
the code).
Quite frankly, I would point out that you probably would not allow
pldebugger to run on a production system, as well as you probably will
not debug your production application thing. flipping the coin, it
could be that requiring superuser privileges to attach the debugger is
a good thing, so you normal poor user don't risk to attach a malicious
debugger in a production environment (because you don't have superuser
privileges in a production environment, right?).
But again, I suspect only the authors can explain that.

Luca