Re: Directory/File Access Permissions for COPY and Generic File Access Functions - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> * Kevin Grittner (kgrittn@ymail.com) wrote:
>> What's interesting and disappointing here is that not one of these
>> suggested vulnerabilities seems like a possibility on a database
>> server managed in what I would consider a sane and secure manner[1].

> For my part- I agree completely with this sentiment, and I'm not sure
> that Tom disagrees with it.

Well, the issues we've thought of so far require that the attacker have
his own shell-level access to the filesystem, but I would not like to
posit that there are none that don't require it.  Race conditions, for
example, could be exploited without a shell account as long as you can
fire up two backends doing your bidding.  *Maybe* it's safe if we don't
expose any "create symlink" or "create hardlink" or "rename" functions;
but you can bet people will be asking for such things down the line,
and we might forget and give it to them :-(

More to the point, if you're excluding cases like "let the user use
server-side COPY for speed" as allowed use-cases for this feature,
it seems like that's a pretty severe restriction.  How much is left
other than "let DBAs read the postmaster log remotely"?  And do we really
need to provide allegedly-not-superuser-equivalent filesystem access in
order to satisfy that use-case?  If you are letting untrustworthy people
read the postmaster log you've already got security problems, as per other
recent threads.

> I believe the discussion is heading towards
> a blanket "use this at your own risk- if the user can modify files in
> these directories outside of PG, they can probably break your system"
> being added in very bold lettering in the documentation around this.

> It botheres me that we'd have to have a statement like that, but if we
> have to then we have to.

If you're going to need a "use at your own risk" disclaimer, how is
that significantly different from letting people use the existing
superuser filesystem access functions?

>> This feature is valuable because it is an alternative to allowing a
>> user you don't trust *either* an OS login to the database server
>> *or* a superuser database login.  Can anyone suggest an exploit
>> which would be available if we allowed someone who has permission
>> to view all data in the database read permission to the pg_log
>> directory and the files contained therein, assuming they do *not*
>> have an OS login to the database server?

Capture the postmaster log.  Keep on capturing it till somebody
fat-fingers their login to the extent of swapping the username and
password (yeah, I've done that, haven't you?).  Scrape password from
the connection-failure log entry, figure out who it belongs to from
the next successful login, away you go.  Mean time to break-in might
or might not be less than time to brute-force the MD5 you could've
read from pg_authid.  But in any case, I don't find the assumption
that the user can already read everything in the database to
correspond to an untrusted user, so I'm not sure what this exercise
proves.

Or in short: you really shouldn't give server-filesystem access to
a user you have no trust in, and I'm unclear on what the use case
would be for that even if we could restrict it reliably.  The use
cases I can see for this are for DBAs to be able to do maintenance
things remotely without using a full no-training-wheels superuser
account.  ISTM that that type of use-case would be satisfied well
enough --- not ideally, perhaps, but well enough --- by being able
to grant full filesystem read and/or write to non-superuser accounts.

I compare this to the CREATEROLE privilege: that's pretty dangerous,
all in all, but we have not felt the need to invent facilities
whereby somebody could say "joe can create new roles, but only
on alternate Tuesdays and only if their names begin with 'u'".
        regards, tom lane