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