On Fri, Jul 1, 2022 at 5:15 AM Hannu Krosing wrote:
> This is the eternal problem with security - more security always
> includes more inconvenience.
But the same amount of security can be more or less inconvenient, and
I don't think your proposal does very well there. More inconvenience
doesn't
On 7/1/22 05:14, Hannu Krosing wrote:
On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
On Thu, Jun 30, 2022 at 11:52:20AM -0400, Robert Haas wrote:
> I don't think this would be very convenient in most scenarios,
This is the eternal problem with security - more security always
includes mo
And thanks to Robert and Bruce for bringing up good points about
potential pitfalls!
I think we do have a good discussion going on here :)
---
Hannu
On Fri, Jul 1, 2022 at 11:14 AM Hannu Krosing wrote:
>
> On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
> >
> > On Thu, Jun 30, 2022 at 11:
On Thu, Jun 30, 2022 at 7:25 PM Bruce Momjian wrote:
>
> On Thu, Jun 30, 2022 at 11:52:20AM -0400, Robert Haas wrote:
> > I don't think this would be very convenient in most scenarios,
This is the eternal problem with security - more security always
includes more inconvenience.
Unlocking your do
On Thu, Jun 30, 2022 at 11:52:20AM -0400, Robert Haas wrote:
> I don't think this would be very convenient in most scenarios, and I
> think it would also be difficult to implement correctly. I don't think
> you can get by with just having superuser() return false sometimes
> despite pg_authid.rolsu
On Wed, Jun 29, 2022 at 3:46 AM Hannu Krosing wrote:
> terminal 1:
> psql
> hannuk=# select pg_backend_pid();
> pg_backend_pid
>
> 1749025
> (1 row)
>
> terminal 2:
> echo 1749025 > $PGDATA/allow_superuser
>
> back to terminal 1 still connected to backend with pid 1749025
Ah, I see.
My counterclaim was that there are lots of use cases where one would
want to be extra sure that *only* they, as the owner of the database,
can access the database as a superuser and not someone else. Even if
there is some obscure way for that "someone else" to either connect as
a superu
On Wed, 2022-06-29 at 00:05 -0700, Andres Freund wrote:
> On 2022-06-29 08:51:10 +0200, Laurenz Albe wrote:
> > On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > > > Experience shows that 99% of the time one can run PostgreSQL just fine
> > > > without a superuser
> > >
> > > IME that's
The idea is to allow superuser, but only in case you *already* have
access to the file system.
You could think of it as a two factor authentication for using superuser.
So in the simplest implementation it would be
touch $PGDATA/allow_superuser
psql
hannuk=# CREATE EXTENSION ...
rm $PGDATA/all
Hi,
On 2022-06-29 08:51:10 +0200, Laurenz Albe wrote:
> On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > > Experience shows that 99% of the time one can run PostgreSQL just fine
> > > without a superuser
> >
> > IME that's not at all true. It might not be needed interactively, but that
On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > Experience shows that 99% of the time one can run PostgreSQL just fine
> > without a superuser
>
> IME that's not at all true. It might not be needed interactively, but that's
> not all the same as not being needed at all.
I also disagre
On Tue, 2022-06-28 at 23:18 +0200, Hannu Krosing wrote:
> I was not after *completely* removing it, but just having an option
> which makes the superuser() function always return false.
Did you test that? I'm guessing that would cause lots of problems,
e.g., installing extensions.
Regards,
Hi,
On 2022-06-27 23:36:53 +0200, Hannu Krosing wrote:
> My current thinking is (based on more insights from Andres) that we
> should also have a startup flag to disable superuser altogether to
> avoid bypasses via direct manipulation of pg_proc.
To me that makes no sense whatsoever. You're not g
I was not after *completely* removing it, but just having an option
which makes the superuser() function always return false.
For known cases of needing a superuser there would be a way to enable
it , perhaps via a sentinel file or pg_hba-like configuration file.
And as first cut I would advocate
On Mon, Jun 27, 2022 at 5:37 PM Hannu Krosing wrote:
> My current thinking is (based on more insights from Andres) that we
> should also have a startup flag to disable superuser altogether to
> avoid bypasses via direct manipulation of pg_proc.
>
> Experience shows that 99% of the time one can run
On Mon, 2022-06-27 at 23:36 +0200, Hannu Krosing wrote:
> My current thinking is (based on more insights from Andres) that we
> should also have a startup flag to disable superuser altogether to
> avoid bypasses via direct manipulation of pg_proc.
What do you mean by "disable superuser altogether"
My current thinking is (based on more insights from Andres) that we
should also have a startup flag to disable superuser altogether to
avoid bypasses via direct manipulation of pg_proc.
Experience shows that 99% of the time one can run PostgreSQL just fine
without a superuser, so having a superuse
On Sat, 2022-06-25 at 00:08 +0200, Hannu Krosing wrote:
> Hi Pgsql-Hackers
>
> As part of ongoing work on PostgreSQL security hardening we have
> added a capability to disable all file system access (COPY TO/FROM
> [PROGRAM] , pg_*file*() functions, lo_*() functions
> accessing files, etc) in a w
Having a superuser.conf file could also be used to solve another issue
- currently, if you remove the SUPERUSER attribute from all users your
only option to get it back would be to run in single-user mode. With
conf file one could add an "always" option there which makes any
matching user superuser
What are your ideas of applying a change similar to above to actually
being a superuser ?
That is adding a check for "superuser being currently available" to
function superuser() in
./src/backend/utils/misc/superuser.c ?
It could be as simple as a flag that can be set only at startup for
maximum
> On 25 Jun 2022, at 03:08, Hannu Krosing wrote:
>
> Currently the file system access is controlled via being a SUPREUSER
My 2 cents. Ongoing work on making superuser access unneeded seems much more
relevant to me.
IMO superuser == full OS access available from postgres process. I think
the
On Sat, Jun 25, 2022 at 1:13 AM Andres Freund wrote:
>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The problem w
(please don't top-post. Surely you've been around this community long
enough to know that)
On Sat, Jun 25, 2022 at 1:59 AM Hannu Krosing wrote:
> My understanding was that unless activated by admin these changes
> would change nothing.
>
That is assuming you can do this with changing just a co
Hi,
On 2022-06-25 01:23:36 +0200, Hannu Krosing wrote:
> Are you claiming that one can manipulate PostgreSQL to do any file
> writes directly by manipulating pg_proc to call the functions "in a
> wrong way" ?
Yes.
> My impression was that this was largely fixed via disabling the old
> direct f
(fixed your top-posting)
On Fri, Jun 24, 2022 at 4:59 PM Hannu Krosing wrote:
> On Sat, Jun 25, 2022 at 1:46 AM Gurjeet Singh wrote:
> >
> > On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> > > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> >
> > > > 3) should this be back-patched (
The old versions should definitely not have it turned on by default. I
probably was not as clear as I thought in bringing out that point..
For upcoming next ones the distributors may want to turn it on for
some more security-conscious ("enterprize") distributions.
-- Hannu
On Sat, Jun 25, 2022 a
On Friday, June 24, 2022, Gurjeet Singh wrote:
> On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
>
> > > 3) should this be back-patched (we can provide batches for all
> > > supported PgSQL versions)
> >
> > Err, what?
>
> Translation:
My understanding was that unless activated by admin these changes
would change nothing.
And they would be (borderline :) ) security fixes
And the versioning policy link actually does not say anything about
not adding features to older versions (I know this is the policy, just
pointing out the inf
On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > 3) should this be back-patched (we can provide batches for all
> > supported PgSQL versions)
>
> Err, what?
Translation: Backpatching these changes to any stable versions will
not be acc
On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> Hi,
>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The pro
On Sat, Jun 25, 2022 at 1:23 AM Hannu Krosing wrote:
> My impression was that this was largely fixed via disabling the old
> direct file calling convention, but then again I did not pay much
> attention at that time :)
I meant of course direct FUNCTION calling convention (Version 0
Calling Conve
On Sat, Jun 25, 2022 at 1:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The pr
Hi,
On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> Currently the file system access is controlled via being a SUPREUSER
> or having the pg_read_server_files, pg_write_server_files and
> pg_execute_server_program roles. The problem with this approach is
> that it will not stop an attacker who
On Sat, Jun 25, 2022 at 12:08:13AM +0200, Hannu Krosing wrote:
> As part of ongoing work on PostgreSQL security hardening we have
> added a capability to disable all file system access (COPY TO/FROM
> [PROGRAM] , pg_*file*() functions, lo_*() functions
> accessing files, etc) in a way that can not
On Fri, Jun 24, 2022 at 3:08 PM Hannu Krosing wrote:
>
> 1) would it be enough to just disable WRITING to the filesystem (COPY
> ... TO ..., COPY TO ... PROGRAM ...) or are some reading functions
> also potentially exploitable or at least making attackers life easier
> ?
>
I would protect read p
Hi Pgsql-Hackers
As part of ongoing work on PostgreSQL security hardening we have
added a capability to disable all file system access (COPY TO/FROM
[PROGRAM] , pg_*file*() functions, lo_*() functions
accessing files, etc) in a way that can not be re-enabled without
already having access to the f
36 matches
Mail list logo
