* Russell Smith ([EMAIL PROTECTED]) wrote:
> Tom mentioned that he had not had these security concerns raised before.
> From
> my point of view I just have no idea about the level of information offered
> to any given user and am scared to run PostgreSQL in an ISP shared
> environment because
On Sat, May 14, 2005 at 12:25:01PM +1000, Russell Smith wrote:
> - Which parts of other databases can be seen by users?
The name, username of the owner, etc. No table names, for example.
The user list is also visible to everyone, across databases.
> - What is the best method to restrict connect
On Sat, 14 May 2005 04:34 am, Andrew Dunstan wrote:
>
> Andrew - Supernews wrote:
>
> >>
> >>1) The "ISP" case, where you want to hide all catalog information from the
> >>users except the database owner or superuser.
> >>
> >>
> >
> >I don't believe this is ever feasible in practice, since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The problem is that LO descriptors are only valid for the
> duration of the transaction.
Thanks, that's it all right. I forgot to update the lo_ stuff
when we switched the autocommit mojo around a while back.
> I think you should make the func()
Dann,
> What Rada Chirkova is looking for is an endorsement of the project.
Well, let me read up on the research -- it's more than a little unclear just
from the abstract what the code is supposed to accomplish. You just posted
it a few days ago, and I really haven't had time to follow up. We
Dann,
> Could someone on the official PostgreSQL team raise their hand, please,
> and say: "We are interested in folding in this valuable research study
> back into the core of PostgreSQL, thus making it much stronger and more
> capable than it is now."
As much as I would love to do just that, yo
What Rada Chirkova is looking for is an endorsement of the project.
The work has already been completed and studied in detail but on PG
7.3.4 rather than using the current code base.
The plan is to redo it with grad students and careful supervision to
ensure the highest quality.
She wants to kno
Hello all,
Thank you to all who replied for suggestions and help. Enclosed please find
code changes for the following items:
- Allow COPY to understand \x as a hex byte, and
- Add XML output to COPY
The changes include implementation of the features as well as modification
of the copy regression t
On Fri, May 13, 2005 at 10:22:06AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In fact I've seen many more people with this problem after 8.0 was
> > released, at least in pgsql-es-ayuda.
>
> Which problem exactly? Most of the 8.0 complaints I can recall seemed
> to co
Hackers,
I'm looking at the grammar modifications for the 2PC patch, and I am
wondering if we should leave PREPARE TRANSACTION in the same parser/
UtilityStmt node TransactionStmt or should use a different parser node,
say PrepTransactionStmt.
Using a different parser node seems to leave a gram.c
I am very, very sure that anything that makes PostgreSQL stronger will
be deeply appreciated by the PostgreSQL team.
To the PG team, see the following:
http://dbgroup.ncsu.edu/
http://www4.ncsu.edu/~rychirko/
Especially:
http://research.csc.ncsu.edu/selftune/
This is a fabulous project with smas
Tom Lane wrote:
> We should wait and see what field experience is like with
> that, rather than insisting on anything as anal-retentive as disallowing
> 8-bit data in SQL_ASCII.
I didn't suggest changing the behaviour of SQL_ASCII..
-O
---(end of broadcast)---
> I did look over them. Maybe I'd get the whole thing better if I had a
> brief description of each view rather that having to infer the purpose
> for myself from an sql statement of a list of fields. If you're
> concerned to make a case I think that would be useful. If that's been
> published and
Andrew - Supernews wrote:
Most significantly, there is a lot of comment on what people _think_
we could do (or not do), and no comment about what we actually _did_.
I strongly suggest to anyone thinking of commenting on them that you
actually install them and look at them first - while the project
On Thu, May 12, 2005 at 04:03:39PM -0400, Andrew Dunstan wrote:
> I still don't have any strong views, but I do want the target audience
> specified - I have seen conflicting messages on that. Power users? Admin
> Tool builders? Client library builders? These groups don't all have the
> same nee
Andrew - Supernews wrote:
1) The "ISP" case, where you want to hide all catalog information from the
users except the database owner or superuser.
I don't believe this is ever feasible in practice, since client interfaces
at any level higher than libpq will need to access metadata correspond
FOlks,
> The problem seems to be that pg_ctl expects the PID file to be in $PGDATA,
> but the file actually gets written by the postmaster to the actual data
> directory. You can work around this by setting "external_pid_file", but
> this then prevents you from using external_pid_file for another
On 2005-05-13, Josh Berkus wrote:
> Andrew,
>> It might be safer, but that doesn't hit my target at all. I am aiming at
>> a zero-knowledge user, i.e. one who cannot discover anything at all
>> about the db. The idea is that even if subvert can subvert a client and
>> get access to the db the amou
On 2005-05-13, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Josh Berkus wrote:
>>Doesn't it seem like a really complete set of system views (based on
>>information_schema or otherwise) would potentially allow securing the
>>pg_catalog?
>
> Not really, no. It would just be one more thing that my ha
Andrew,
> It might be safer, but that doesn't hit my target at all. I am aiming at
> a zero-knowledge user, i.e. one who cannot discover anything at all
> about the db. The idea is that even if subvert can subvert a client and
> get access to the db the amount of metadata they can discover is as
>
Josh Berkus wrote:
Andrew,
Not really, no. It would just be one more thing that my hardening script
had to remove permissions from.
Hmmm ... even though the sysviews check users' permissions? That was one of
our ideas behind making it "safer than the system catalogs".
It might be safe
Andrew,
> Not really, no. It would just be one more thing that my hardening script
> had to remove permissions from.
Hmmm ... even though the sysviews check users' permissions? That was one of
our ideas behind making it "safer than the system catalogs".
> I still have an open mind about the sy
Josh Berkus wrote:
Andrew, Merlin,
My approach was to remove all significant permissions (including on the
catalog) from public and regrant them to a pseudopublic group,
comprising designated users. The designated users would notice no
difference at all, while everyone else would be able to see
Josh Berkus writes:
> Andrew, Merlin,
>> My approach was to remove all significant permissions (including on the
>> catalog) from public and regrant them to a pseudopublic group,
>> comprising designated users. The designated users would notice no
>> difference at all, while everyone else would be
Andrew, Merlin,
> My approach was to remove all significant permissions (including on the
> catalog) from public and regrant them to a pseudopublic group,
> comprising designated users. The designated users would notice no
> difference at all, while everyone else would be able to see only what
> w
Merlin Moncure wrote:
I tried it from that angle and could only come up with two modes:
'pgadmin on' and 'pgadmin off' (per user). If you can do better, I'd be
thrilled. I also don't want to overblow my own argument...the database
can be secured quite effectively if you know what to do. It woul
Andrew Dunstan wrote:
> Tom Lane wrote:
> >"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> >>However, I think PostgreSQL has a fairly serious security problem in
> >>that the system catalogs are open to the public. I don't seem to be
> >>winning many supporters on this particular point though.
> >
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
However, I think PostgreSQL has a fairly serious security problem in
that the system catalogs are open to the public. I don't seem to be
winning many supporters on this particular point though.
No, you're not, and it's not like
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> However, I think PostgreSQL has a fairly serious security problem in
> that the system catalogs are open to the public. I don't seem to be
> winning many supporters on this particular point though.
No, you're not, and it's not like we've never heard
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Argument 3: backwards compatibility. Do you remember how
tablespaces
> > introduction broke pgAdmin?
>
> This argument, at least, is bogus. See my original comments to Josh:
> it is not credible that these views will be significa
On Fri, May 13, 2005 at 09:59:27AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The problem is that a single application coming from a single
> > environment is happy with a 8-bit-unchecked encoding, but as soon as
> > they develop a second application using a different e
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In fact I've seen many more people with this problem after 8.0 was
> released, at least in pgsql-es-ayuda.
Which problem exactly? Most of the 8.0 complaints I can recall seemed
to come from people who were trying to dump from a SQL_ASCII database
and r
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that a single application coming from a single
> environment is happy with a 8-bit-unchecked encoding, but as soon as
> they develop a second application using a different environment, which
> uses a different encoding, they start seeing i
On Fri, May 13, 2005 at 01:15:36AM -0400, Tom Lane wrote:
> We are currently seeing a whole lot of complaints due to the fact that
> 8.0 tends to default to Unicode encoding in environments where previous
> versions defaulted to SQL-ASCII. That says to me that a whole lot of
> people were getting
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 11, 2005 2:22 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
>
> "Dave Held" <[EMAIL PROTECTED]> writes:
> > /*
> >
Another difficulty with establishing prior art to prevent others from
obtaining patents is that different inventors and different patent
agents or attorneys use different terminology to describe the same or
similar inventions.
To use a simple mechanical example:
- Alex develops gadget that i
On Thu, May 12, 2005 at 16:59:07 -0700,
David Fetter <[EMAIL PROTECTED]> wrote:
>
> A PostgreSQL developer has shown in this very thread that it is
> extremely easy to screw up a query against those catalogs. Maybe
> you're better than he is, but that's not a reason to keep something
> simpler
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Peter Eisentraut wrote:
>>
>>>That would cripple a system that many users are perfectly content with now.
>
>
>>Well, I wasn't thinking of using a 7-bit encoding always, just as a
>>replacement for the cases where we currently choos
Andrew - Supernews wrote:
On 2005-05-12, Andreas Pflug <[EMAIL PROTECTED]> wrote:
relpages is updated from the value of RelationGetNumberOfBlocks(rel) which
is definitive (it gets the value from smgr which gets it from the physical
file sizes); the only inaccuracy is that it is correct only as of
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Berkus
> Sent: 12 May 2005 18:04
> To: Andreas Pflug
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Server instrumentation for 8.1
>
> Andreas,
>
> > First, as some other msg stat
40 matches
Mail list logo
