Re: About "ERROR: must be *superuser* to COPY to or from a file"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: "John D(dot) Burger" <john(at)mitre(dot)org>, Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: About "ERROR: must be *superuser* to COPY to or from a file"
Date: 2005-08-29 23:59:53
Message-ID: 15067.1125359993@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I was only suggesting using this from a local unix user where you can
> actually authoritatively say something about the uid of the connecting
> user. I suggested that if the owner of the file matches the uid of the
> connecting user (which you can get on a unix domain socket)

... on some platforms ... and half the world connects over TCP even on
local connections ...

> then there's no reason not to grant access to the file.

Assuming that the server itself can get at the file, which is
questionable if the file is owned by the connecting user rather than the
server (and, for instance, may be located under a not-world-readable
home directory). And then there are interesting questions like whether
the server and the user see eye-to-eye on the name of the file (consider
server inside chroot jail, AFS file systems, etc).

There are enough holes in this to make it less than attractive. We'd
spend more time answering questions about "why doesn't this work" than
we do now, and I remain unconvinced that there would be no exploitable
security holes.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Clodoaldo Pinto 2005-08-30 00:41:21 update functions locking tables
Previous Message Tom Lane 2005-08-29 23:39:09 Re: About dropped notifications