* sumita (su...@avaya.com) wrote:
> Does postgresql support the use of security labels or sensitivity markings?
For tables, yes, but not yet for rows/RLS. There is ongoing work in
this area and the hope is that there will be some form of RLS in 9.5.
As mentioned, security barrier views can be u
On Mon, Jul 14, 2014 at 2:23 AM, sumita wrote:
> Does postgresql support the use of security labels or sensitivity
> markings?
>
>
>
If what you want is some kind of row-level security, you have to roll your
own when using PostgreSQL. Security_barrier views are a good option for
this. See:
http
They don't apply server-wide. They apply to that user's session:
http://www.postgresql.org/docs/8.4/interactive/sql-set.html
Geoff
On Wed, Apr 30, 2014 at 6:19 AM, Hello World wrote:
>
> SET statement_timeout=0;
>> SET work_mem=1024GB;
>>
>
> I just realized about the SET command.
>
> Isn't i
> SET statement_timeout=0;
> SET work_mem=1024GB;
>
I just realized about the SET command.
Isn't it weird that any user can set parameters such as this that will
apply server wide? to all future sessions?
I noticed that some of the parameters can only be set by superusers, and
some require re-st
Hello World wrote:
> Denial of service is indeed a problem. Is there a way to limit the execution
> time of a request?
Yes, setting statement_timeout.
But if a client can exectue arbitrary statements, that could also
be statements like:
SET statement_timeout=0;
SET work_mem=1024GB;
> I'm using
On Wed, Apr 30, 2014 at 12:32 AM, Hello World wrote:
> Hello!
>
> I'm developing a web application that needs to display data from a
> postgres backend.
>
> The most convenient way for the app to get the data is by expressing the
> request in SQL.
>
> I'm thinking about the following architecture
On 30/04/14, Hello World (worldani...@gmail.com) wrote:
> I'm developing a web application that needs to display data from a postgres
> backend.
>
> The most convenient way for the app to get the data is by expressing the
> request in SQL.
>
> I'm thinking about the following architecture
>
> [
Hello,
Thank you very much.
Denial of service is indeed a problem. Is there a way to limit the
execution time of a request?
I'm using libpq to communicate with the server.
PS. I've just taken a look, it seems I could do some asynchronous queries,
time them, then cancel them if they take too lon
Hello World wrote:
> Given this are there any security other issues about letting client
> applications execute arbitrary SQL
> commands on the backend database?
There shouldn't be any security problems, just be careful that you don't give
the
user more permissions than you want to.
But a user
Maybe this link answers your query:
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
On 3/6/13, Atri Sharma wrote:
> Hi all,
>
> A couple of folks in my college are doing a review of security
> features in various databases present today. Specifically, how these
> features measure up against each
On Sun, Sep 11, 2011 at 12:44 AM, Sim Zacks wrote:
> The problem with trust is that it means that any user can type in any other
> users login name and get access without knowing his password. Even if your
> app is the only access point to the database, you still have to worry about
> a user insta
On 09/11/2011 02:58 PM, mgo...@isstrucksoftware.net wrote:
Sim,
Thanks, our users can only get to the application(s) they have on
their citrix menu. They are locked out of the servers otherwise. I
haven't had a problem in the past 20 years with another db back end
but I do think that on th
The problem with trust is that it means that any user can type in any
other users login name and get access without knowing his password. Even
if your app is the only access point to the database, you still have to
worry about a user installing psql or other client onto his desktop and
accessin
In response to "Jasbinder Singh Bali" <[EMAIL PROTECTED]>:
> Hi,
>
> The way postgres has the concept of host base authentication, is this a step
> forward over other RDBMS like sql server and oracle?
Host-based auth has been around a long time. It's just another layer.
Some folks even consider
On Fri, Mar 09, 2007 at 01:07:23 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Certainly --- the point here is merely that that isn't the *default*
> behavior. We judged quite some time ago that allowing public execute
> access was the most useful default. Perhaps that was a bad choice, but
>
In response to "Ted Byers" <[EMAIL PROTECTED]>:
> >
> > Functions are controlled by the same ACL mechanism that tables and
> > everything
> > else follows. Thus you have the idea of "user id X may do Y with object
> > Z"
> > i.e. "user "barbara" may "execute" function "somefunction()".
> >
> > B
"Ted Byers" <[EMAIL PROTECTED]> writes:
> ... Can
> I make a function as a part of a schema that is executable only by the owner
> and other functions in the schema, and no-one else, and still have a
> publically callable function in that schema invoke the "private" function?
Certainly --- the
Functions are controlled by the same ACL mechanism that tables and
everything
else follows. Thus you have the idea of "user id X may do Y with object
Z"
i.e. "user "barbara" may "execute" function "somefunction()".
But there's no real way to alter those permissions outside of changing the
us
In response to "Ted Byers" <[EMAIL PROTECTED]>:
>
> - Original Message -
> From: "Bill Moran" <[EMAIL PROTECTED]>
>
> > In response to Rikard Pavelic <[EMAIL PROTECTED]>:
> >
> >> Tom Lane wrote:
> >> > No, it's operating as designed. Per the GRANT reference page:
> >> > : Depending on t
On 3/8/07, Rikard Pavelic <[EMAIL PROTECTED]> wrote:
Bill Moran wrote:
>> Hmm, so the answer to my question
>> "How can I assign execute permission to a role for a single function
>> inside schema."
>> is I can't?
>>
>
> How did you interpret "do it like this" to mean "you can't do it"?
>
> REVO
On 08/03/2007 22:21, Rikard Pavelic wrote:
And for user2 to be able to execute
example.function2() and not example.function1()?
REVOKE EXECUTE ON FUNCTION example.function1() FROM user1
don't have any affect.
Surely you mean -
REVOKE EXECUTE ON FUNCTION example.function1() FROM user2;
Shane Ambler wrote:
You can but the default is to allow the execution of all functions.
You need to revoke the existing permission of executing all functions
before you can allow only a single function to be run.
If you want a specific function to be accessed only by selected roles
then you
Bill Moran wrote:
Hmm, so the answer to my question
"How can I assign execute permission to a role for a single function
inside schema."
is I can't?
How did you interpret "do it like this" to mean "you can't do it"?
REVOKE ALL ON FROM PUBLIC;
So this basically means that I can't fi
Rikard Pavelic wrote:
Tom Lane wrote:
No, it's operating as designed. Per the GRANT reference page:
: Depending on the type of object, the initial default privileges may
: include granting some privileges to PUBLIC. The default is no public
: access for tables, schemas, and tablespaces; CONNECT
- Original Message -
From: "Bill Moran" <[EMAIL PROTECTED]>
To: "Rikard Pavelic" <[EMAIL PROTECTED]>
Cc: "Tom Lane" <[EMAIL PROTECTED]>;
Sent: Thursday, March 08, 2007 3:18 PM
Subject: Re: [GENERAL] security permissions for functions
In response to Rikard Pavelic <[EMAIL PROTECTED]>:
> Tom Lane wrote:
> > No, it's operating as designed. Per the GRANT reference page:
> > : Depending on the type of object, the initial default privileges may
> > : include granting some privileges to PUBLIC. The default is no public
> > : access f
Tom Lane wrote:
No, it's operating as designed. Per the GRANT reference page:
: Depending on the type of object, the initial default privileges may
: include granting some privileges to PUBLIC. The default is no public
: access for tables, schemas, and tablespaces; CONNECT privilege and TEMP
: ta
Rikard Pavelic <[EMAIL PROTECTED]> writes:
> Is this a bug or something?
No, it's operating as designed. Per the GRANT reference page:
: Depending on the type of object, the initial default privileges may
: include granting some privileges to PUBLIC. The default is no public
: access for tables,
On 22 Jan 2007 at 10:15, Ron Johnson wrote:
> On 01/22/07 09:55, Jan Muszynski wrote:
> > On 22 Jan 2007 at 16:10, Sim Zacks wrote:
> >
> >> How good is postgresql security? For example, If I have data
> >> that I do not anyone to see, including the programmer/dba, is
> >> it enough to change the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/22/07 09:55, Jan Muszynski wrote:
> On 22 Jan 2007 at 16:10, Sim Zacks wrote:
>
>> How good is postgresql security? For example, If I have data
>> that I do not anyone to see, including the programmer/dba, is
>> it enough to change the password
On 22 Jan 2007 at 16:10, Sim Zacks wrote:
> How good is postgresql security?
> For example, If I have data that I do not anyone to see, including the
> programmer/dba, is it enough
> to change the password to the only user?
> If they have access to the raw files is there a way for them to someho
On Mon, Jan 22, 2007 at 08:30:53AM -0600, Ron Johnson wrote:
> > The answer depends heavily on what the "programmer/dba" can do.
> >
> > Any superuser of the DB can see any data
> > Any user that can access the raw files can see any data
> > Any user that can poke into memory can see any data
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/22/07 08:22, Martijn van Oosterhout wrote:
> On Mon, Jan 22, 2007 at 04:10:15PM +0200, Sim Zacks wrote:
>> How good is postgresql security?
>
> Good, within limits.
>
>> For example, If I have data that I do not anyone to see, including the
>>
On Mon, Jan 22, 2007 at 04:10:15PM +0200, Sim Zacks wrote:
> How good is postgresql security?
Good, within limits.
> For example, If I have data that I do not anyone to see, including the
> programmer/dba, is it enough to change the password to the only user?
> If they have access to the raw fil
am Mon, dem 22.01.2007, um 16:10:15 +0200 mailte Sim Zacks folgendes:
> How good is postgresql security?
> For example, If I have data that I do not anyone to see, including the
> programmer/dba, is it enough to change the password to the only user?
> If they have access to the raw files is there
Joshua Kramer <[EMAIL PROTECTED]> writes:
> I am writing a couple of Perl modules that talk to the outside world: one
> talks to a database (via DBI), and one talks to a Jabber/XMPP server. I
> want to use these from within a Trigger.
This is most likely a bad idea for reasons that have nothing
On Fri, 2005-09-30 at 09:14, jeff sacksteder wrote:
> Are there any data access issues (as opposed to data visibility
> issues)
> you are having?
>
>
> No, It's just that in a hosting situation where each customer has a
> database of their own, they need to be boxed in somehow. In
Are there any data access issues (as opposed to data visibility issues)
you are having?
No, It's just that in a hosting situation where each customer has a
database of their own, they need to be boxed in somehow. In the event
of an application bug allowing raw sql to be executed, it's not
appropri
jeff sacksteder wrote:
The security documentation available in the official documentation is rather
sparse. Is there a more detailed document I should be aware of?
No.
As an example, I'd like to prevent a a user from being able to get a list of
existing databases. Presumably, I can limit acce
Am Donnerstag, 29. September 2005 21:46 schrieb jeff sacksteder:
> As an example, I'd like to prevent a a user from being able to get a list
> of existing databases.
You can't do that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
I've updated my Perl script to accommodate the version of the
procedures in the final release notes:
http://www.sitening.com/postgresql-update-2005-1
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th A
Douglas McNaught <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Also, note that that message was the zero-day-security-problem response
>> to the issue, and that we since figured out cleaner responses. If you
>> haven't yet implemented this in your own DBs, I would suggest f
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> http://www.postgresql.org/about/news.315
>
> Also, note that that message was the zero-day-security-problem response
> to the issue, and that we since figured out cleaner responses. If you
> haven't yet implem
Neil Conway <[EMAIL PROTECTED]> writes:
> Note that if you're upgrading within a release series (e.g. 8.0.x to
> 8.0.3) without a dump and reload, you will _not_ get the necessary
> system catalog changes automatically. Tom's earlier mail describes the
> procedure needed to correct the system ca
Marc G. Fournier wrote:
Please note that the security issues were those already reported by Tom
Lane, as well as a manual fix for them. These releases are mainly to
ensure that those installing and/or upgrading existing installations
have those fixes automatically.
Note that if you're upgrading
On Sat, Feb 05, 2005 at 11:00:28PM -0800, David Fetter wrote:
> On Sat, Feb 05, 2005 at 09:08:00PM -0500, Ron Peterson wrote:
> > I would like to be able to assert that the security of data stored
> > as a value in a PostgreSQL table can be as high as the security of
> > saving that same piece of d
On Sat, Feb 05, 2005 at 09:08:00PM -0500, Ron Peterson wrote:
> I would like to be able to assert that the security of data stored
> as a value in a PostgreSQL table can be as high as the security of
> saving that same piece of data to a file on disk. Would that be
> correct?
I hate to put it so
On Sat, Feb 05, 2005 at 09:08:00PM -0500, Ron Peterson wrote:
> I would like to be able to assert that the security of data stored as a
> value in a PostgreSQL table can be as high as the security of saving
> that same piece of data to a file on disk. Would that be correct?
Theoretically, definit
On 02/05/2005 08:08:00 PM, Ron Peterson wrote:
I would like to be able to assert that the security of data stored as
a
value in a PostgreSQL table can be as high as the security of saving
that same piece of data to a file on disk. Would that be correct?
Well, from a theoretical perspective you're
Devrim GUNDUZ wrote:
* Updated PyGreSQL from 3.4 to 3.5 (only for 7.4.6-2PGDG)
Given the fact that PyGreSQL is still affected by the unfamous
"idle in transaction" behaviour:
def __init__(self, cnx):
self.__cnx = cnx
self.__cache = pgdbTypeCache(cnx)
try:
src
On Tue, 11 May 2004, [EMAIL PROTECTED] wrote:
> hello,
>
> i'm very new to postgres and have a fundamental question.
> how do i make a pg-db most secure?
> i feel, that pg_user e.g. ist something very dangerous - isn't it? if
> someone hacks into a db, then he has lots of information at his/her
> i'm very new to postgres and have a fundamental question.
> how do i make a pg-db most secure?
> i feel, that pg_user e.g. ist something very dangerous - isn't it? if
> someone hacks into a db, then he has lots of information at his/her
> fingertips. is this so?
>
> what do i do to prevent my
On Tue, May 11, 2004 at 20:09:46 +0200,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> i'm very new to postgres and have a fundamental question.
> how do i make a pg-db most secure?
> i feel, that pg_user e.g. ist something very dangerous - isn't it? if
> someone hacks into a db, then he ha
53 matches
Mail list logo
