Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Sun, Jan 29, 2017 at 05:52:51PM -0500, Robert Haas wrote: > On Sun, Jan 29, 2017 at 5:39 PM, David Fetter wrote: > > On Thu, Jan 26, 2017 at 08:50:27AM -0500, Robert Haas wrote: > >> On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: > >> > Frankly, I

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Sun, Jan 29, 2017 at 5:39 PM, David Fetter wrote: > On Thu, Jan 26, 2017 at 08:50:27AM -0500, Robert Haas wrote: >> On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: >> > Frankly, I get quite tired of the argument essentially being made >> > here

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Thu, Jan 26, 2017 at 08:50:27AM -0500, Robert Haas wrote: > On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: > > Frankly, I get quite tired of the argument essentially being made > > here that because pg_ls_dir() wouldn't grant someone superuser > > rights, that we

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 12:32 PM, Stephen Frost wrote: > You're completely ignoring the use-cases for which these are being done. > > I've outlined the precise use-case for pgstattuple()'s usage across the > entire database for which the admin has granted the EXECUTE access

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

> On 27 Jan 2017, at 17:39, Stephen Frost wrote: > > Greetings, > > * Simon Riggs (si...@2ndquadrant.com) wrote: >>> On 27 January 2017 at 14:09, Dave Page wrote: On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Greetings, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 27 January 2017 at 14:09, Dave Page wrote: > > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > > > >> If the monitoring tool requires superuser then that is a problem, so > >> it would

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> OK, fair enough. get_raw_page() is clearly not something that we > >> really want everybody to have access to

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 27 January 2017 at 14:09, Dave Page wrote: > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > >> If the monitoring tool requires superuser then that is a problem, so >> it would be helpful if it didn't do that, please. Not much use having >> a

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> OK, fair enough. get_raw_page() is clearly not something that we >> really want everybody to have access to by default, but if it were up >> to me, I'd change the

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Simon Riggs writes: > > [ good general plan ] > > > 3. Make a list of all functions that would cause security problems. > > One by one, precisely. If we did remove all superuser checks we would > > need this list documented to

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > OK, fair enough. get_raw_page() is clearly not something that we > really want everybody to have access to by default, but if it were up > to me, I'd change the permissions check inside the function to do a > check for select privileges on

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane wrote: > Robert Haas writes: >> The problem is if the interpretation functions aren't completely >> bulletproof, they might do things like crash the server if you use >> them to read a corrupt page. That is not

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert Haas writes: > The problem is if the interpretation functions aren't completely > bulletproof, they might do things like crash the server if you use > them to read a corrupt page. That is not any more appealing if you > happen to be running as superuser() than

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane wrote: > Robert Haas writes: >> - contrib/pageinspect has lots of superuser checks, basically because >> they have known input-validation weaknesses. See >> 3e1338475ffc2eac25de60a9de9ce689b763aced for the

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs wrote: > This is still just the Adminpack argument. This has been going on for > about a decade? Longer. Right. > If the monitoring tool requires superuser then that is a problem, so > it would be helpful if it didn't do that,

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert Haas writes: > - contrib/pageinspect has lots of superuser checks, basically because > they have known input-validation weaknesses. See > 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail. FWIW, I think that's a bit of an oversimplification.

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Thu, Jan 26, 2017 at 5:36 PM, Stephen Frost wrote: >> The first is that restricting the ability to GRANT access >> to a function, even a function that allows escalation to superuser >> privileges, doesn't improve security, because the superuser can still >> grant those

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > On 27 January 2017 at 12:56, Dave Page wrote: > >> Probably the most common complaint I get from users >> regarding the management & monitoring tools I work on is that they >> have to use superuser

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 27 January 2017 at 12:56, Dave Page wrote: > Probably the most common complaint I get from users > regarding the management & monitoring tools I work on is that they > have to use superuser accounts to get the full benefits, unlike other > DBMSs where you can create a role

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Simon Riggs writes: > [ good general plan ] > 3. Make a list of all functions that would cause security problems. > One by one, precisely. If we did remove all superuser checks we would > need this list documented to advise people of the risks, so it must > exist before

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 1:02 PM, Simon Riggs wrote: > On 26 January 2017 at 22:36, Stephen Frost wrote: > >>> Currently, I count three votes in favor of this approach and one >>> opposed. If anyone else wants to weigh in, please do. It would be >>>

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 26 January 2017 at 22:36, Stephen Frost wrote: >> Currently, I count three votes in favor of this approach and one >> opposed. If anyone else wants to weigh in, please do. It would be >> helpful if anyone weighing in can be clear about whether (a) they are >> in favor of

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Thu, Jan 26, 2017 at 10:36 PM, Stephen Frost wrote: > > Perhaps unsuprisingly, but you've still not convinced me, so I don't > agree with this change. > >> Currently, I count three votes in favor of this approach and one >> opposed. If anyone else wants to weigh in, please

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Stephen Frost wrote: > I agree that it'd be nice if others would weigh in on this. I support your position. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: > > Frankly, I get quite tired of the argument essentially being made here > > that because pg_ls_dir() wouldn't grant someone superuser rights, that > > we should

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 10:31 PM, Stephen Frost wrote: > Frankly, I get quite tired of the argument essentially being made here > that because pg_ls_dir() wouldn't grant someone superuser rights, that > we should remove superuser checks from everything. As long as you are >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Your proposed policy is essentially that functions should have > built-in superuser checks if having access to that function is > sufficient to escalate your account to full superuser privileges. Yes, I do. > 1. There's no consensus on any

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 8:22 PM, Stephen Frost wrote: > Apparently we disagree about what is a 'reasonable manner'. Yes. I think that a "reasonable manner" should mean "what the DBA thinks is reasonable", whereas you apparently think it should mean "what the DBA thinks is

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 18:04:09 -0500, Stephen Frost wrote: > > Robert's made it clear that he'd like to have a blanket rule that we > > don't have superuser checks in these code paths if they can be GRANT'd > > at the database level, which goes beyond

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 2017-01-25 18:04:09 -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > > > * Robert Haas (robertmh...@gmail.com) wrote: > > > > Preventing people from calling functions by denying the ability to > > > >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > Preventing people from calling functions by denying the ability to > > > meaningfully GRANT EXECUTE on those functions doesn't actually

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Hi, On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > Preventing people from calling functions by denying the ability to > > meaningfully GRANT EXECUTE on those functions doesn't actually stop > > them from delegating those functions to

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 3:17 PM, Stephen Frost wrote: > > Your email is 'pg_ls_dir & friends', which I took to imply at *least* > > pg_read_file() and pg_read_binary_file(), and it's not unreasonable to > > think you may

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 3:17 PM, Stephen Frost wrote: > Your email is 'pg_ls_dir & friends', which I took to imply at *least* > pg_read_file() and pg_read_binary_file(), and it's not unreasonable to > think you may have meant everything in adminpack, which also includes >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:08 PM, Stephen Frost wrote: > > That isn't what you're doing with those functions though, you're giving > > the monitoring tool superuser-level rights but trying to pretend like > > you're not. >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:13 PM, Stephen Frost wrote: > > I went over *every* superuser check in the system when I did that work, > > wrote up a long email about why I made the decisions that I did, posted > > it here,

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 2:13 PM, Stephen Frost wrote: > I went over *every* superuser check in the system when I did that work, > wrote up a long email about why I made the decisions that I did, posted > it here, had follow-on discussions, all of which lead to the patch which

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 2:08 PM, Stephen Frost wrote: > That isn't what you're doing with those functions though, you're giving > the monitoring tool superuser-level rights but trying to pretend like > you're not. Uh, how so? None of those functions can be used to escalate

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Also, the same argument could be made about removing the built-in > superuser check from ANY function, and we've already rejected that > argument for a bunch of other functions. If we say that argument is > valid for some functions but not

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Greg, * Greg Stark (st...@mit.edu) wrote: > I tend to agree. But in the past when this came up people pointed out > you could equally do things this way and still grant all the access > you wanted using SECURITY DEFINER. Arguably that's a better approach > because then instead of auditing the

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > The use case I have in mind is > a monitoring tool that needs access to one more of those functions -- > in keeping with the principle of least privilege, it's much better to > give the monitoring user only the privileges which it actually

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 11:30 AM, Greg Stark wrote: > I tend to agree. But in the past when this came up people pointed out > you could equally do things this way and still grant all the access > you wanted using SECURITY DEFINER. Arguably that's a better approach > because then

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

I tend to agree. But in the past when this came up people pointed out you could equally do things this way and still grant all the access you wanted using SECURITY DEFINER. Arguably that's a better approach because then instead of auditing the entire monitor script you only need to audit this one

[HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Commit 1574783b4ced0356fbc626af1a1a469faa6b41e1 gratifyingly removed hard-coded superuser checks from assorted functions, which makes it possible to GRANT EXECUTE ON FUNCTION pg_catalog.whatever() to unprivileged users if the DBA so desires. However, the functions in genfile.c still have