On Mon, Aug 01, 2022 at 02:41:21PM -0700, Jacob Champion wrote:
> On 7/13/22 12:49, Tom Lane wrote:
>> Nathan Bossart writes:
>>> Given the discussion in this thread, I intend to mark the commitfest entry
>>> as Withdrawn shortly.
>
> I'll mark this RwF rather than bring it forward; if you'd pref
On 7/13/22 12:49, Tom Lane wrote:
> Nathan Bossart writes:
>> Given the discussion in this thread, I intend to mark the commitfest entry
>> as Withdrawn shortly.
I'll mark this RwF rather than bring it forward; if you'd prefer a
different status please feel free (or let me know).
Thanks,
--Jacob
Nathan Bossart writes:
> Given the discussion in this thread, I intend to mark the commitfest entry
> as Withdrawn shortly. Before I do, I thought I'd first check whether 0001
> [0] might be worthwhile independent of $SUBJECT. This change separates the
> [un]trusted handler and validator functio
Given the discussion in this thread, I intend to mark the commitfest entry
as Withdrawn shortly. Before I do, I thought I'd first check whether 0001
[0] might be worthwhile independent of $SUBJECT. This change separates the
[un]trusted handler and validator functions for PL/Perl so that we no
lon
On 24.05.22 22:58, Nathan Bossart wrote:
FWIW this was my original thinking. I can choose to build/install
extensions separately, but when it comes to PL/Tcl and PL/Perl, you've
got to build the trusted and untrusted stuff at the same time, and the
untrusted symbols remain even if you remove the
Stephen Frost writes:
> I agree that this seems to need more discussion and explanation as it
> isn't actually sufficient by itself for "anyone who wants to disallow
> file system access" as the initial post claimed. If there isn't
> sufficient explanation coming forward to support this change by
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The very specific "it'd be nice to build PG w/o having untrusted
> > languages compiled in" is at least reasonably clearly contained and
> > reasonable to see if we are, in fact, doing what we claim we're doing
> > with
Stephen Frost writes:
> The very specific "it'd be nice to build PG w/o having untrusted
> languages compiled in" is at least reasonably clearly contained and
> reasonable to see if we are, in fact, doing what we claim we're doing
> with such a switch.
I agree that it's specific and easily measur
On Wed, May 25, 2022 at 4:07 PM Stephen Frost wrote:
> The very specific "it'd be nice to build PG w/o having untrusted
> languages compiled in" is at least reasonably clearly contained and
> reasonable to see if we are, in fact, doing what we claim we're doing
> with such a switch. A switch that
On Wed, May 25, 2022 at 2:28 PM Tom Lane wrote:
> I'm a little skeptical that our present design direction really moves
> the needle very far in this area. We've sliced and diced superuser
> aplenty, but that doesn't make individual capabilities such as
> pg_write_all_data or ALTER SYSTEM any les
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I really don't think this is going to be anywhere near as
> > straight-forward as it might appear to be to prevent a superuser from
> > being able to break out of PG.
>
> This gets back to the point I made before about
Stephen Frost writes:
> I really don't think this is going to be anywhere near as
> straight-forward as it might appear to be to prevent a superuser from
> being able to break out of PG.
This gets back to the point I made before about it not being worthwhile
to implement half-measures. There is
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> I guess I'd ask again whether we can do both... We've got predefined roles
> like pg_execute_server_program that allow access to COPY TO/FROM PROGRAM,
> but I have no way to categorically disable that Ń•ort of thing if I wanted
> to r
On Tue, May 24, 2022 at 09:19:40PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I always thought if pg_proc is able to call an arbitrary function in an
> > arbitrary library, it could access to the file system, and if that is
> > true, locking the super-user from file system access seems imp
Bruce Momjian writes:
> I always thought if pg_proc is able to call an arbitrary function in an
> arbitrary library, it could access to the file system, and if that is
> true, locking the super-user from file system access seems impossible
> and unwise to try because it would give a false sense of
On Tue, May 24, 2022 at 02:10:19PM -0400, Robert Haas wrote:
> I guess one question is at what level we want to disable these various
> things. Your original proposal seemed reasonable to me because I feel
> like users who are compiling PostgreSQL ought to have control over
> which things they comp
On Tue, May 24, 2022 at 02:10:19PM -0400, Robert Haas wrote:
> I guess one question is at what level we want to disable these various
> things. Your original proposal seemed reasonable to me because I feel
> like users who are compiling PostgreSQL ought to have control over
> which things they comp
On Tue, May 24, 2022 at 1:28 PM Nathan Bossart wrote:
> Can we do both? That is, can we add retail options for untrusted
> languages, generic file access functions, etc., and then also introduce a
> --disable-disk-access configuration option? The latter might even just be
> a combination of reta
Nathan Bossart writes:
> On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:
>> No, my point is that one size doesn't fit all. Bundling everything
>> together that could result in a disk access is going to suck too many
>> marginally-related into the same bucket. It's much better to have
On Tue, May 24, 2022 at 12:39:16PM -0400, Robert Haas wrote:
> On Mon, May 23, 2022 at 6:42 PM Tom Lane wrote:
>> [ shrug... ] So is your point that we shouldn't bother to do anything?
>> I don't personally have a problem with leaving things where they stand
>> in this area. However, if we're go
On Mon, May 23, 2022 at 6:42 PM Tom Lane wrote:
> [ shrug... ] So is your point that we shouldn't bother to do anything?
> I don't personally have a problem with leaving things where they stand
> in this area. However, if we're going to do something, I think at
> minimum it should involve blocki
On 5/23/22 8:04 PM, Nathan Bossart wrote:
On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:
Instead, I'd argue that we should be continuing to work in the direction
of splitting up what can only be done by a superuser today using
predefined roles and other methods along those lines.
On Mon, May 23, 2022 at 07:09:03PM -0400, Stephen Frost wrote:
> Instead, I'd argue that we should be continuing to work in the direction
> of splitting up what can only be done by a superuser today using
> predefined roles and other methods along those lines. How that lines up
> with this latest
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > It's not just a question of whether it was meant to be SQL-callable --
> > it's also a question of what arguments it was expecting to be called
> > with. At the very least, you can cause the server to core dump if you
> >
Robert Haas writes:
> It's not just a question of whether it was meant to be SQL-callable --
> it's also a question of what arguments it was expecting to be called
> with. At the very least, you can cause the server to core dump if you
> pass something that isn't a valid pointer to a function that
On Mon, May 23, 2022 at 4:46 PM Tom Lane wrote:
> Maybe I shouldn't be putting words into Nathan's mouth, but I think
> what he is after is a mode intended for use by cloud service providers,
> who would like to offer locked-down database services where there's
> just no way to get to the disk fro
Robert Haas writes:
> I definitely think there's a need for a user who can manipulate
> objects in the database much like a superuser (i.e. access all
> objects, grant and revoke all privileges, etc.) but who can't break
> out into the OS user account and assume it's privileges. I'm not sure
> whe
On Mon, May 23, 2022 at 1:17 PM Tom Lane wrote:
> There would probably be some interest in a "--disable-disk-access"
> configure option that did all of this stuff (and some more things
> too), with the aim of locking down *all* known paths to filesystem
> access. I don't see much value in retail
On Mon, May 23, 2022 at 02:20:02PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> That's a reasonable point. I'll go ahead an explore some options for
>> something along those lines. A couple of questions immediately come to
>> mind. For example, should this configuration option just cause
Nathan Bossart writes:
> That's a reasonable point. I'll go ahead an explore some options for
> something along those lines. A couple of questions immediately come to
> mind. For example, should this configuration option just cause these
> functions to ERROR, or should it compile them out?
Let
On Mon, May 23, 2022 at 01:17:08PM -0400, Tom Lane wrote:
> There would probably be some interest in a "--disable-disk-access"
> configure option that did all of this stuff (and some more things
> too), with the aim of locking down *all* known paths to filesystem
> access. I don't see much value i
Nathan Bossart writes:
> On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:
>> Lastly, you've offered no reason to think this would provide any real
>> security improvement. Someone who's gained the ability to issue CREATE
>> EXTENSION on untrusted extensions has already got all the privil
On Fri, May 20, 2022 at 08:20:11PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need
>> to make a couple of code changes to compile out the untrusted parts. I
>> suspect many users (e.g., anyone who wants to disallow file
Nathan Bossart writes:
> Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need
> to make a couple of code changes to compile out the untrusted parts. I
> suspect many users (e.g., anyone who wants to disallow file system access)
> would benefit from a better supported way to d
34 matches
Mail list logo
