From: David Steele <david@pgmasters.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Suralkar, Yogendra (Yogendra) <suralkary@avaya.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Cc: Porob, Dattaram (Datta) <porobd@avaya.com>
Cc: Oswal, Prashant (Prashant) **CTR** <poswal@avaya.com>
Cc: Patil, Parag (Parag) <paragp@avaya.com>
Cc: Devaraj, Sankar (Sankar) <devarajs@avaya.com>
Cc: Singh, Payal (Payal) **CTR** <payals@avaya.com>
Subject: Re: Unable to connect to PostgreSQL DB as root user when private key is owned by root with permission 640
Date: Tue, 24 May 2022 16:33:12 -0400
Message-ID: <2af73dd7-6ea2-b5f2-9b35-76e6a8f2a54a@pgmasters.net> (raw)
In-Reply-To: <1719047.1653422732@sss.pgh.pa.us>
References: <MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com>
<335500.1653058186@sss.pgh.pa.us>
<1719047.1653422732@sss.pgh.pa.us>
On 5/24/22 16:05, Tom Lane wrote:
> I wrote:
>> TBH, my immediate reaction is "what are you doing running database
>> accesses as root?".
That was my first thought as well. Kind of throws a lot of security out
the window anyway.
>> But given that you are, I see the problem: the test
>> is coded like
>> if ((buf.st_uid == geteuid() && buf.st_mode & (S_IRWXG | S_IRWXO)) ||
>> (buf.st_uid == 0 && buf.st_mode & (S_IWGRP | S_IXGRP | S_IRWXO)))
>> which was copied verbatim from the equivalent test in the backend.
>> However, in the backend it's safe to assume that geteuid() != 0.
>> libpq apparently shouldn't assume that, meaning that the two arms
>> of the if aren't disjoint cases anymore, and it matters which one
>> we check first.
Indeed it does.
> After further poking at this, I see that we also have to drop the check of
> file ownership. That was already dropped once long ago (3405f2b9253), on
> the grounds that if the file has suitable permissions but its ownership
> isn't what we expect then our read attempt will fail, so we needn't check
> ownership explicitly. While I'd prefer a more explicit error than the
> "Permission denied" that you get with this approach, the intent of this
> patch was not to create any new failure modes, so I think we're stuck
> with that.
That makes sense. Seems I should have dug further into why the server
does this but the client does not.
> Open questions:
>
> * This puts us back into a situation where the frontend and server tests
> are not in sync. Do we want to relax the server's checks to match this,
> or just leave that side as it stands?
I'm inclined to leave it as is in the back branches to avoid any other
unintended consequences. Perhaps we could make the change for PG15?
> * I notice that while the code comments and error messages insist that
> we're checking for 0600/0640 or less, the actual test is not that:
> it doesn't look at S_IXUSR, so it will allow 0700 or 0740. Do we want
> to do anything about that? TBH I'm content to leave it as-is.
> Rejecting S_IXUSR doesn't seem like it buys any useful increment of
> security, and I'm now afraid that somebody will complain that it
> breaks their case that used to work. OTOH, updating the error messages
> and documentation to match the code reality is not terribly attractive
> either; it'll cause a lot of translation churn and probably add more
> confusion than it removes.
I'd rather leave this alone in the back branches as well. Another thing
to consider for PG15 but I agree it does not appear to be a security issue.
Regards,
-David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: david@pgmasters.net, tgl@sss.pgh.pa.us, suralkary@avaya.com, pgsql-bugs@lists.postgresql.org, porobd@avaya.com, poswal@avaya.com, paragp@avaya.com, devarajs@avaya.com, payals@avaya.com
Subject: Re: Unable to connect to PostgreSQL DB as root user when private key is owned by root with permission 640
In-Reply-To: <2af73dd7-6ea2-b5f2-9b35-76e6a8f2a54a@pgmasters.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox