Tom Lane wrote:
> "Larry Rosenman" 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.
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=>
"Larry Rosenman" 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 warnings,
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 wrote:
> ohp@pyrenet.fr wrote:
>> On Mon, 25 Jul 2005, Larry Rosenman wrote:
>>
>>> Date: 25 Jul 2005 12:47:01 -0500
>>> From: Larry Rosenman
>>> To: ohp@pyrenet.fr
>>> Cc: pgsql-hackers list
>>> Subject: Re: [HACKERS] regression failure on latest CVS
>>>
>>> On Jul 25 2005, ohp@
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
To: ohp@pyrenet.fr
Cc: pgsql-hackers list
Subject: Re: [HACKERS] regression failure on latest CVS
On Jul 25 2005, ohp@pyrenet.fr wrote:
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
To: ohp@pyrenet.fr
Cc: pgsql-hackers list
Subject: Re: [HACKERS] regressio
* 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 wi
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 (
> 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'
> > ORD
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 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]~:47>nm `locate libpython|grep .so`
>
> /usr/local/lib/compat/pkg/libpython2.3.so.1:
> /usr/libexec
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 clos
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 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]~:47>nm `locate libpython|gr
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:
> >>
> >>
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, 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 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 hand
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 libra
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
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;
> U
ohp@pyrenet.fr wrote:
> On Mon, 25 Jul 2005, Larry Rosenman wrote:
>
>> Date: 25 Jul 2005 12:47:01 -0500
>> From: Larry Rosenman
>> To: ohp@pyrenet.fr
>> Cc: pgsql-hackers list
>> Subject: Re: [HACKERS] regression failure on latest CVS
>>
>> On Jul 25 2005, ohp@pyrenet.fr wrote:
>>
>>> Hi Larr
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.*
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 ca
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:
> >
> >
> http://www.pgbuildfarm.org/cgi-bin/sho
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 (
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 i
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:
>>>
>>>
>> http://www.pgb
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 p
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
EXPLAI
> -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 abo
On Mon, 25 Jul 2005, Larry Rosenman wrote:
> Date: 25 Jul 2005 12:47:01 -0500
> From: Larry Rosenman
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 25 2005, ohp@pyrenet.fr wrote:
>
> > Hi Larry,
> >
> > I'm quitge sure you'll se
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
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> On Jul 25 2005, ohp@pyrenet.fr wrote:
>
> > Hi
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
--
* 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 woul
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
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 ab
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
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers l
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 u
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 broadcast)-
* 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
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 shoul
* 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
[ 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 feat
Tom Lane wrote:
> Bruce Momjian 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?
>
> Lik
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian 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 regression tests are fine now.
Bruce Momjian 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 recall some prior
Tom Lane wrote:
> Bruce Momjian 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 table fields that
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 swi
> > 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
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 lo
> >> 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
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
* 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 wr
"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 p
> > 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 .so.
>
> Yeah, I w
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 writt
"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.
>
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 buildfar
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
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
> > 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 co
63 matches
Mail list logo
