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

On 2017-01-25 18:04:09 -0500, Stephen Frost wrote:
> Andres,
> 
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote:
> > > * Robert Haas (robertmhaas@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 non-superusers.  It either (a)
> > > > causes them to give superuser privileges to accounts that otherwise
> > > > would have had lesser privileges or (b) forces them to use wrapper
> > > > functions to grant access rather than doing it directly or (c) some
> > > > other dirty hack.  If they pick (a), security is worse; if they pick
> > > > (b) or (c), you haven't prevented them from doing what they wanted to
> > > > do anyway.  You've just made it annoying and inconvenient.
> > >
> > > The notion that security is 'worse' under (a) is flawed- it's no
> > > different.
> > 
> > Huh? Obviously that's nonesense, given the pg_ls_dir example.
> 
> 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 pg_ls_dir.

That seems right to me.  I don't see much benefit for the superuser()
style checks, with a few exceptions.  Granting by default is obviously
an entirely different question.


> If the question was only about pg_ls_dir, then I still wouldn't be for
> it, because, as the bits you didn't quote discussed, it encourages users
> and 3rd party tool authors to base more things off of pg_ls_dir to
> look into the way PG stores data on disk, and affords more access than
> the monitoring user has any need for, none of which are good, imv.  It
> also discourages people from implementing proper solutions which you can
> 'just use pg_ls_dir()', which I also don't agree with.

In other words, you're trying to force people to do stuff your preferred
way, instead of allowing them to get things done is a reasonable manner.


> If you really want to do an ls, go talk to the OS.  ACLs are possible to
> provide that with more granularity than what would be available through
> pg_ls_dir().  We aren't in the "give a user the ability to do an ls"
> business, frankly.

Wut.


> > > I am suggesting that we shouldn't make it look like there are
> > > distinctions when there is actually no difference.  That is a good thing
> > > for our users because it keeps them informed about what they're actually
> > > doing when they grant access.
> > 
> > This position doesn't make a lick of sense to me.  There's simply no
> > benefit at all in requiring to create wrapper functions, over allowing
> > to grant to non-superuser. Both is possible, secdef is a lot harder to
> > get right. And you already heavily started down the path of removing
> > superuser() type checks - you're just arguing to make it more or less
> > randomly less consistent.
> 
> I find this bizarre considering I went through a detailed effort to go
> look at every superuser check in the system and discussed, on this list,
> the reasoning behind each and every one of them.  I do generally
> consider arbitrary access to syscalls via the database to be a privilege
> which really only the superuser should have.

Just because you argued doesn't mean I agree.


Greetings,

Andres Freund