It could be argued that there should be provision for a
limitation on
the locations in which COPY can write (and maybe read) files.
If COPY is a security hole then we should close it, not use that as
precedent to open another hole.
Yeah. It's worth pointing out in this connection
Magnus Hagander wrote:
Instead of trying to pick on one feature, how about trying something
constructive instead? Let's say we add a GUC like restrict_superuser,
that disables COPY to local files, untrusted procedural languages (both
creation and using the ones that already exist), the new
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.
It could be a compiler optimizer bug or the way the code is written.
Could someone point me to the source
Tom Lane wrote:
One pretty silly point: I notice that
http://www.pgbuildfarm.org/index.html
says The build farm software does not currently run on Windows.
This is out of date no?
Fixed, thanks.
One not so trivial question: do we have a policy about system/compiler
updates on buildfarm
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah. It's worth pointing out in this connection that
server-side COPY is already pretty well crippled if you are
running under SELinux, because the security policy constrains
what parts of the filesystem the daemon can reach at all.
I don't
On Jul 25 2005, ohp@pyrenet.fr wrote:
Sorry to follow up my own post but this is weird.
I've tested again and more closely.
And intervall check is ok when configured with --enable-debug and fails
(with the same error) otherwise.
It could be a compiler optimizer bug or the way the code is
snip good explanation. Thanks.
Let me suggest another nice way for a superuser to do
whatever he wants.
How about CREATE UNTRUSTED PROCEDURAL LANGUAGE? If you have say
pl/perl or pl/tcl on the system, you just create the
untrusted version
and away you go - because they use the same
Magnus Hagander [EMAIL PROTECTED] writes:
That'd be fine with me --- but we have to introduce that
*before* we add obvious new security risks, not after.
So what do you think of the proposed GUC?
Well, it has more or less the same problem as the GUC in the
COPY-only-to-given-places proposal,
* Tom Lane ([EMAIL PROTECTED]) wrote:
didn't. One way that the attacker might proceed is to try to make a .so
file that he can LOAD into the backend containing the equivalent of a
system() function. I believe this is not feasible using COPY in its
current form, mainly because you can't write
Andrew Dunstan wrote:
It also just strikes me as just the wrong way to go about solving the
apparent problem. If we want to make remote configuration or other
operations possible, then instead of granting access to server resident
files we should invent and implement an API that provides
That'd be fine with me --- but we have to introduce that
*before* we add obvious new security risks, not after.
So what do you think of the proposed GUC?
Well, it has more or less the same problem as the GUC in the
COPY-only-to-given-places proposal, which is that GUCs were
never
Andrew Dunstan [EMAIL PROTECTED] writes:
I still think, security considerations aside, that an API for config
settings would be a much better piece of design than providing file
system access functions.
I agree with that. Given what we currently have, though, remote config
and remote log
I still think, security considerations aside, that an API
for config
settings would be a much better piece of design than providing file
system access functions.
I agree with that.
For the record, me too. But I don't see that happening for 8.1,
considering the feature freeze and
Stephen Frost [EMAIL PROTECTED] writes:
If you want to secure your system against a superuser()-level intrusion
then you need to secure the unix account, or disable creation of
C-language and other untrusted languages (at least).
Very likely --- which is why Magnus' idea of an explicit switch
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
FYI, I am seeing the same stats regression failures in CVS, even after
the recent commits to improve sleep().
As near as I can tell, this is fixed by pgstat.c rev 1.101. I'm not
clear why --- the patch certainly zeroes some
Bruce Momjian pgman@candle.pha.pa.us writes:
Andrew Dunstan wrote:
It also just strikes me as just the wrong way to go about solving the
apparent problem.
I thought an API for postgresql.conf is what we agreed to, but I don't
see it on the TODO list. Is that correct?
Like you, I seem to
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
FYI, I am seeing the same stats regression failures in CVS, even after
the recent commits to improve sleep().
Has anyone else seen this failure since updating to latest pgstat.c?
My
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Andrew Dunstan wrote:
It also just strikes me as just the wrong way to go about solving the
apparent problem.
I thought an API for postgresql.conf is what we agreed to, but I don't
see it on the TODO list. Is that correct?
[ getting back to this thread... ]
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
I think a better answer is to have a rolinherit flag in pg_authid,
which people can set off for spec compatibility or on for backwards
compatibility to the GROUP feature. In
* Tom Lane ([EMAIL PROTECTED]) wrote:
[ getting back to this thread... ]
Happy to, was getting worried you'd forgotten or ignored it. ;)
* rolinherit = false: role does not automatically have the privileges of
roles it is a member of. It must do SET ROLE to gain the privileges of
a role it
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
everything behaves per spec, except that I don't want to support the
aspect of the spec that says you can SET ROLE at the outer level and
still have the privileges of the SESSION_USER. I think SET ROLE should
* Tom Lane ([EMAIL PROTECTED]) wrote:
The problem I have with the spec's way is that it creates a disconnect
between the privilege environment seen at the outer level and the
environment seen within SECURITY DEFINER functions --- unless you want
to allow SET ROLE to have the union behavior
Andrew Dunstan wrote:
It could be argued that there should be provision for a limitation on
the locations in which COPY can write (and maybe read) files.
Please note that the genfile functions are already restricted.
Regards,
Andreas
---(end of
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
The problem I have with the spec's way is that it creates a disconnect
between the privilege environment seen at the outer level and the
environment seen within SECURITY DEFINER functions
Essentially the union
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
This is the problem I have.
Regards
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 09:00:41 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc:
Andreas Pflug wrote:
Andrew Dunstan wrote:
It could be argued that there should be provision for a limitation on
the locations in which COPY can write (and maybe read) files.
Please note that the genfile functions are already restricted.
Yes, that's what I thought. The argument is
On Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
Do we have a clue as to which .c module the compiler/optimizer is (possibly)
screwing up?
I have connections in SCO's compiler group
* Tom Lane ([EMAIL PROTECTED]) wrote:
My understanding of things is that per spec, a SECURITY DEFINER function
can be owned by either a user or a role, and so within the function
either CURRENT_USER or CURRENT_ROLE would return the owner and the other
would return NULL. Emulating this would
On Fri, 22 Jul 2005 19:11:36 -0400
Tom Lane [EMAIL PROTECTED] wrote:
BTW, I'd like to look at 302906, but its [Details] link is broken.
Ugh, I tried digging onto the internal systems and it looks like they
were destroyed (or not saved) somehow. It'll have to be rerun.
Sorry...
Mark
On Jul 25 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
On Jul 25
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
On Jul 25 2005, ohp@pyrenet.fr wrote:
Hi Larry,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 25 July 2005 15:18
To: Magnus Hagander
Cc: Andrew Dunstan; Andreas Pflug; Bruce Momjian; Dave Page;
PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
Or what about a
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail = 'test'
ORDER BY cs.fullname;
Unless I'm missing something, the ORDER BY clause has no effect, but an
On Sun, Jul 24, 2005 at 06:01:46PM -0600, Michael Fuhr wrote:
On Sun, Jul 24, 2005 at 06:40:35PM -0400, Tom Lane wrote:
I think someone mentioned this already, but it'd be a good idea to
compare the python situation to plperl. On my Linux box, libperl.so
shows several references to
Jim C. Nasby wrote:
On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:
Andrew Dunstan wrote:
Larry,
please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:
Would it be useful to hackers if build animals periodically ran builds
with those options removed?
On Mon, Jul 25, 2005 at 07:19:05PM +0200, ohp@pyrenet.fr wrote:
Hi Larry,
I'm quitge sure you'll see a problem if you remove --enable-debug
--enable-cassert from your ./configure
This is the
On Mon, Jul 25, 2005 at 08:49:45AM -0400, Andrew Dunstan wrote:
We don't consider configuration settings ( e.g.
--enable-integer-datetimes or --with-perl) to be part of the
personality, and we don't currently track changes in them, nor in
versions of third party libraries we might use (
On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:
Andrew Dunstan wrote:
Larry,
please try building and testing (especially PL installcheck) on that
box using as close as possible to the same config setup as octopus:
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 19:08 -0300, Marc G. Fournier wrote:
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 18:11 -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a
On Mon, 2005-07-25 at 19:08 -0300, Marc G. Fournier wrote:
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 18:11 -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
On Jul 25 2005,
On Mon, Jul 25, 2005 at 06:11:08PM -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail = 'test'
ORDER BY cs.fullname;
Unless
Am Montag, den 25.07.2005, 18:11 -0300 schrieb Marc G. Fournier:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail = 'test'
ORDER BY cs.fullname;
Jim C. Nasby wrote:
On Mon, Jul 25, 2005 at 08:49:45AM -0400, Andrew Dunstan wrote:
We don't consider configuration settings ( e.g.
--enable-integer-datetimes or --with-perl) to be part of the
personality, and we don't currently track changes in them, nor in
versions of third party
On Sun, Jul 24, 2005 at 10:55:08AM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
A problem with this patch is that it assumes a version of Python
based on the OS, which might clean up the current buildfarm but
that isn't really correct. Is there a better way to handle this?
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 18:11 -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail
On Mon, 25 Jul 2005, Jim C. Nasby wrote:
On Mon, Jul 25, 2005 at 06:11:08PM -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail
On Mon, Jul 25, 2005 at 07:06:46PM -0300, Marc G. Fournier wrote:
On Mon, 25 Jul 2005, Jim C. Nasby wrote:
On Mon, Jul 25, 2005 at 06:11:08PM -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
On Mon, Jul 25, 2005 at 04:03:58PM -0600, Michael Fuhr wrote:
On Mon, Jul 25, 2005 at 04:40:19PM -0500, Jim C. Nasby wrote:
FWIW, AFAICT I did build the port with default options. Though, nm shows
no symbols for my libpython(s)...
[EMAIL PROTECTED]:38]~:47nm `locate libpython|grep .so`
Using an 8.0.3 database, if I do:
CREATE GROUP testgrp WITH USER pgsql;
GRANT ALL ON timezone TO GROUP testgrp;
DROP GROUP testgrp;
The table permissions still contain the reference to the 'group':
public | timezone| table| {pgsql=arwdRxt/pgsql,group
100=arwdRxt/pgsql}
On Mon, Jul 25, 2005 at 05:54:45PM -0400, Larry Rosenman wrote:
Jim C. Nasby wrote:
On Sun, Jul 24, 2005 at 07:38:46PM -0400, Larry Rosenman wrote:
Andrew Dunstan wrote:
Larry,
please try building and testing (especially PL installcheck) on that
box using as close as possible to the
On Mon, Jul 25, 2005 at 04:40:19PM -0500, Jim C. Nasby wrote:
FWIW, AFAICT I did build the port with default options. Though, nm shows
no symbols for my libpython(s)...
[EMAIL PROTECTED]:38]~:47nm `locate libpython|grep .so`
/usr/local/lib/compat/pkg/libpython2.3.so.1:
On Mon, Jul 25, 2005 at 06:11:08PM -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail = 'test'
ORDER BY cs.fullname;
On Mon, Jul 25, 2005 at 06:11:08PM -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be
issued
in a case like:
SELECT c.*
FROM company c, company_summary cs
WHERE c.id = cs.id
AND cs.detail = 'test'
ORDER BY cs.fullname;
On Mon, Jul 25, 2005 at 07:02:37PM -0300, Marc G. Fournier wrote:
Should there not be an ERROR returned when you try and drop a user/group
that has permissions on a table in the database, to prevent this?
Yes, this is a long-standing known bug and has been fixed in 8.1.
--
Alvaro Herrera
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
Should there not be an ERROR returned when you try and drop a user/group
that has permissions on a table in the database, to prevent this?
That's exactly what the shared-dependency patch that was recently
applied to CVS HEAD is supposed to deal
Andrew Dunstan wrote:
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS]
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
Larry Rosenman wrote:
ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Larry Rosenman wrote:
Date: 25 Jul 2005 12:47:01 -0500
From: Larry Rosenman ler@lerctr.org
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
On
On Mon, Jul 25, 2005 at 07:06:33PM -0400, Andrew Dunstan wrote:
Well, the config options are always sent back in status reports... maybe
if there was just a summary page that listed what those options were on
a per-report basis; or even maybe diffing between reports to show
changes.
Larry Rosenman ler@lerctr.org writes:
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new
The new SET ROLE code has a bit of a problem with rollback of SET
operations. For example,
regression=# create user foo;
CREATE ROLE
regression=# create role bar;
CREATE ROLE
regression=# set role bar;
SET
regression= show role;
role
--
bar
(1 row)
regression= begin;
BEGIN
regression=
Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
For those following along at home:
Removing --enable-cassert and --enable-debug from the options causes
Firefly to fail.
FWIW, I just checked that CVS tip works OK for me without these
options, with either integer or float timestamps.
63 matches
Mail list logo
