> > 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
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 buildfar
"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.
>
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
> > 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
"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
* 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
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
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
> > 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
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
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
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
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.
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
[ 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 ([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
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:
> 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 broadcast)-
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
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
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
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 woul
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
> 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 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
> -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
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
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
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
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
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:
> >
> >
> http://www.pgbuildfarm.org/cgi-bin/sho
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 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.*
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, 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
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 libra
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
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:
> >>
> >>
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
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 clos
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 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'
> > ORD
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 wi
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
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:
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@
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" 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,
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" 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
