Re: Directory/File Access Permissions for COPY and Generic File Access Functions

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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 :-(

I was planning to document these concerns in our documentation around
the feature. If we manage to still provide unfettered link() access to
users despite having docs that say we had best not do that, well, that'd
be on us then, yes.

> 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.

Auditors don't need write access to the server, period. They do need to
be able to read the logs though. Additionally, being able to grant this
capability to relatively trusted processes, such as ETL, rather than
ad-hoc users, is a valuable use case for this feature.

> > 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?

I agree that it really isn't (except for the 'you are not actually
running as superuser' bit, as discussed below) and said as much on
another sub-thread a few moment ago.

> >> 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?).

Back to the 'setting up systems sanely'- don't use password based
authentication.

> 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 agree that those use-cases are useful but, even as an admin, I'd be
worried about fat-fingering a filename or similar and overwriting
something unintentionally. Still, it'd be a bit better for trusted
admins than having to run around as full superuser, but I'm still not
sure I'd want to give it to my ETL process.

My hope was specifically to *not* give full and unfettered server
filesystem access through this mechanism, to trusted users or untrusted
ones, as you could trivially become superuser or corrupt files on the
system to cause PG to crash.

> 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'".

Having a FILEACCESS role attribute would certainly be trivial to
implement and document.

Thanks,

Stephen