On 07/16/2013 09:14 PM, I wrote:
But okay, you're saying we *have* and *want* a guarantee that even a
superuser cannot execute arbitrary native code via libpq (at least in
default installs w/o extensions).
I stand corrected and have to change my position, again. For the record:
We do not have
On 07/22/2013 12:11 AM, Hannu Krosing wrote:
Dropping this barrier by installing an untrusted PL (or equally insecure
extensions), an attacker with superuser rights can trivially gain
root.
Could you elaborate ?
This is equivalent to claiming that any linux user can trivially gain root.
Markus Wanner mar...@bluegap.ch writes:
- per-installation (not even per-cluster) DSO availability
Not sure what the issue is, here, but I agree that should be possible.
For any extension where the new package version is shipping the same .so
file name, you can only have one module on the
Dimitri,
On 07/22/2013 08:44 PM, Dimitri Fontaine wrote:
That's the trade-off we currently need to make to be able to ship with
the current security protections we're talking about.
Anything wrong with shipping postgis-1.5.so and postgis-2.0.so, as I we
for Debian?
Ok, here's the full worked
Salut Dimitri,
On 07/20/2013 01:23 AM, Dimitri Fontaine wrote:
Markus Wanner mar...@bluegap.ch writes:
- per-installation (not even per-cluster) DSO availability
If you install PostGIS 1.5 on a system, then it's just impossible to
bring another cluster (of the same PostgreSQL major
On 07/21/2013 10:30 PM, Markus Wanner wrote:
but I will admit having a hard time swallowing
the threat model we're talking about…
An attacker having access to a libpq connection with superuser rights
cannot currently run arbitrary native code. He can try a DOS by
exhausting system resources,
Markus Wanner mar...@bluegap.ch writes:
- per-installation (not even per-cluster) DSO availability
If you install PostGIS 1.5 on a system, then it's just impossible to
bring another cluster (of the same PostgreSQL major version), let
On Debian, that should be well possible.
Markus Wanner mar...@bluegap.ch writes:
But okay, you're saying we *have* and *want* a guarantee that even a
superuser cannot execute arbitrary native code via libpq (at least in
default installs w/o extensions).
There are several problems confused into that sentence already. I think
the next
On 07/17/2013 08:52 PM, Dimitri Fontaine wrote:
the next step of this discussion should be about talking about the
problems we have and figuring out *if* we want to solve them, now that
we managed to explicitely say what we want as a project.
- per-installation (not even per-cluster) DSO
On 07/16/2013 01:27 AM, Robert Haas wrote:
Andres points out that you can install adminpack to obtain
local filesystem access, and that is true. But the system
administrator can also refuse to allow adminpack, and/or use selinux
or other mechanisms to prevent the postgres binary from writing
On Tue, Jul 16, 2013 at 3:14 PM, Markus Wanner mar...@bluegap.ch wrote:
But okay, you're saying we *have* and *want* a guarantee that even a
superuser cannot execute arbitrary native code via libpq (at least in
default installs w/o extensions).
Yes, that's a good way of summarizing my
On 2013-07-14 23:49:47 -0400, Robert Haas wrote:
On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner mar...@bluegap.ch wrote:
One way to resolve that - and that seems to be the direction Dimitri's
patch is going - is to make the extension depend on its template. (And
thereby breaking the mental
Robert,
thanks for answering. I think you responded to the (or some) idea in
general, as I didn't see any relation to the quoted part. (Otherwise
this is a hint that I've not been clear enough.)
On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
There is a lot of
On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
Granted, the internalization of the DSO is somewhat critical to
implement. Running as a non-root user, Postgres has less power than that
and can certainly not protect the internalized DSO from modification by
root. It can, however, store the
On 07/15/2013 12:05 PM, Andres Freund wrote:
A superuser can execute native code as postges user. That's it.
Oh, I though Robert meant postgres users, i.e. non-superusers.
I hereby withdraw my pitchforks: I'm certainly not opposing to simplify
the life of superusers, who already have the power.
On 2013-07-15 12:20:15 +0200, Markus Wanner wrote:
On 07/15/2013 12:05 PM, Andres Freund wrote:
A superuser can execute native code as postges user. That's it.
Oh, I though Robert meant postgres users, i.e. non-superusers.
Oh, I am talking about *postgres* superusers ;). The example
On 07/15/2013 12:19 PM, Andres Freund wrote:
On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
Granted, the internalization of the DSO is somewhat critical to
implement. Running as a non-root user, Postgres has less power than that
and can certainly not protect the internalized DSO from
Robert,
On 07/15/2013 12:12 PM, Markus Wanner wrote:
On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
There is a lot of
(well-founded, IMHO) resistance to the idea of letting users install C
code via an SQL connection.
Nowhere did I propose anything close to that.
On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner mar...@bluegap.ch wrote:
To clarify: In the above agreement, I had the Postgres level ordinary
users in mind, who certainly shouldn't ever be able to upload and run
arbitrary native code.
I'm not quite as enthusiastic if you meant the system
On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner mar...@bluegap.ch wrote:
One way to resolve that - and that seems to be the direction Dimitri's
patch is going - is to make the extension depend on its template. (And
thereby breaking the mental model of a template, IMO. In the spirit of
that
Hi,
let me elaborate on an idea I had to streamline extension templates. As
I wrote in my recent review [1], I didn't have the mental model of a
template in mind for extensions, so far.
However, writing the review, I came to think of it. I certainly agree
that extensions which do not carry a
21 matches
Mail list logo
