Tom Lane wrote:
Kenneth Downs <[EMAIL PROTECTED]> writes:
Except for the hole. On a public site that lets users register, we have
to have way to let the web server assume the role of somebody who has
createuser privelege, and that's pretty much the end of the no-root
policy. If an exploit could be placed, it could simply go into that
mode and create a superuser.
What would be really nice is if you could limit the ability of
CREATEUSER to grant roles.
I believe that a role that has CREATEROLE but not SUPERUSER can only
create non-SUPERUSER roles. Does that help?
regards, tom lane
Probably not. The problem is that a person with createrole can create
any role, so by mistake or exploit a user can be given admin access
(admin here defined by roles given, not by SUPERUSER flag) to another
database by a role that itself is supposed to be a public-only mostly
read-only role.
begin:vcard
fn:Kenneth Downs
n:Downs;Kenneth
adr;dom:;;347 Main Street;East Setauket;NY;11733
email;internet:[EMAIL PROTECTED]
tel;work:631-689-7200
tel;fax:631-689-0527
tel;cell:631-379-0010
x-mozilla-html:FALSE
url:http://www.secdat.com
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
