On 3/10/07, Kenneth Downs <[EMAIL PROTECTED]> wrote:
Alvaro Herrera wrote:
David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role
Alvaro Herrera wrote:
David Legault escribió:
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my functi
David Legault escribió:
> That's basically what I've done with my past questions on the ROLE system in
> place. Since roles are global, I wanted it fine grained to the DB level so I
> had to append DB_ in front of each role name and by using current_database()
> inside my functions, I could hide th
That's basically what I've done with my past questions on the ROLE system in
place. Since roles are global, I wanted it fine grained to the DB level so I
had to append DB_ in front of each role name and by using current_database()
inside my functions, I could hide that from the exterior.
Now I ha
Awesome! That never occurred to me. This is really cool.
Tom Lane wrote:
Kenneth Downs <[EMAIL PROTECTED]> writes:
Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
roles and only grant to the roles he himself is a member of.
You can make that out of spare part
Kenneth Downs <[EMAIL PROTECTED]> writes:
> Perhaps a lesser form of CREATEROLE, CREATEROLE_LIMITED, who can create
> roles and only grant to the roles he himself is a member of.
You can make that out of spare parts today, by granting non-superusers
execute rights on functions that create users.
Tom Lane wrote:
Kenneth Downs <[EMAIL PROTECTED]> writes:
The biggest security limitation we have is actually a weakness in
Postgres - the inability to restrict the abilities of a user with
CREATUSER rights, they can make somebody who can do anything. For
higher security this requires no a
Kenneth Downs <[EMAIL PROTECTED]> writes:
> The biggest security limitation we have is actually a weakness in
> Postgres - the inability to restrict the abilities of a user with
> CREATUSER rights, they can make somebody who can do anything. For
> higher security this requires no ability for pu
On Fri, Mar 09, 2007 at 12:22:19PM -0500, Kenneth Downs wrote:
> >My interest was more towards the "we get an email" part.
> >What level do you send that from ? A trigger ?
> >
> The web framework does that.
I see. IOW if a violation happens below the web layer the
e-mail doesn't get send. I thoug
Kevin Hunter wrote:
What about an SQL injection bug that allows for increased privileges?
Um, web programming 101 is that you escape quotes on user-supplied
inputs. That ends SQL injection.
Pardon my naivete (I'm fairly new to web/DB programming) . . . is this
the current standard method o
What about an SQL injection bug that allows for increased privileges?
Um, web programming 101 is that you escape quotes on user-supplied
inputs. That ends SQL injection.
Pardon my naivete (I'm fairly new to web/DB programming) . . . is this
the current standard method of protection from SQL
Bill Moran wrote:
If a user has not logged in, that is, if they are an anonymous visitor,
the web framework will connect to the database as the default "public"
user. Our system is deny-by-default, so this user cannot actually read
from any table unless specifically granted permission. In the
Kevin Hunter wrote:
If a user has not logged in, that is, if they are an anonymous
visitor, the web framework will connect to the database as the
default "public" user. Our system is deny-by-default, so this user
cannot actually read from any table unless specifically granted
permission. I
quot;Karsten Hilbert" <[EMAIL PROTECTED]>
To:
Sent: Friday, March 09, 2007 11:45 AM
Subject: Re: HIPPA (was Re: [GENERAL] Anyone know ...)
> On Fri, Mar 09, 2007 at 11:02:45AM -0500, Kenneth Downs wrote:
>
>> >>First, security is defined directly in terms of tables, it is
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/07 10:02, Kenneth Downs wrote:
Karsten Hilbert wrote:
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:
First, security is defined directly in terms of tables, it is not
arbitrated by code
Karsten Hilbert wrote:
If the user figures out our URL scheme, they might try something like
"?gp_page=patients" and say "Wow I'm clever I'm going to look at the
patients table", except that the public user has no privilege on the
table. The db server will throw a permission denied error.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/07 10:02, Kenneth Downs wrote:
> Karsten Hilbert wrote:
>> On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:
>>
>>
>>> First, security is defined directly in terms of tables, it is not
>>> arbitrated by code. The "public" group
On Fri, Mar 09, 2007 at 11:02:45AM -0500, Kenneth Downs wrote:
> >>First, security is defined directly in terms of tables, it is not
> >>arbitrated by code. The "public" group has SELECT access to the
> >>articles table and the schedules tables, that's it. If a person figures
> >>out how our
In response to Kevin Hunter <[EMAIL PROTECTED]>:
> >>> First, security is defined directly in terms of tables, it is not
> >>> arbitrated by code. The "public" group has SELECT access to the
> >>> articles table and the schedules tables, that's it. If a person
> >>> figures out how our links
First, security is defined directly in terms of tables, it is not
arbitrated by code. The "public" group has SELECT access to the
articles table and the schedules tables, that's it. If a person
figures out how our links work and tries to access the "claims" table
it will simply come up blank
Karsten Hilbert wrote:
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:
First, security is defined directly in terms of tables, it is not
arbitrated by code. The "public" group has SELECT access to the
articles table and the schedules tables, that's it. If a person figures
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:
> First, security is defined directly in terms of tables, it is not
> arbitrated by code. The "public" group has SELECT access to the
> articles table and the schedules tables, that's it. If a person figures
> out how our links wo
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/08/07 20:38, Kenneth Downs wrote:
[snip]
Management and we are about to add the CRM to it so that the
scheduling/billing database also serves the doctor's public website,
Is that wise? One bug and a cracker is pok
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/08/07 20:38, Kenneth Downs wrote:
[snip]
> Management and we are about to add the CRM to it so that the
> scheduling/billing database also serves the doctor's public website,
Is that wise? One bug and a cracker is poking around some very
privat
24 matches
Mail list logo
