[BUGS] BUG #1112: round(float-type does not work)
The following bug has been logged online: Bug reference: 1112 Logged by: Ulf Mehlig Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian Linux/i386 "testing" Description:round(float-type does not work) Details: After upgrading to 7.4.2 I just discovered that the round(f,d) function does not work as expected (bug or feature?): xxx=> select round(pi(), 2); ERROR: function round(double precision, integer) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. Typecasting to "NUMERIC" helps, but in my opinion it should not be necessary to typecast float values for rounding: xxx=> select round(pi()::numeric, 2); round --- 3.14 (1 row) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1113: Default template databases grant CREATE to PUBLIC
The following bug has been logged online: Bug reference: 1113 Logged by: Oliver Elphick Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian Linux Description:Default template databases grant CREATE to PUBLIC Details: The default database created by initdb (in template0 and template1) grants CREATE permission on the public schema to PUBLIC. Therefore any user is able to create a table or function, including a function that can bring down the machine by (for example) recursively calling itself. By default, any user can create objects in template1, as well. The default should be for CREATE permissions on the public schema to be revoked from PUBLICc. This might break old applications which have not been updated to take account of schemas; the workaround for them would be to grant permissions in template1.public as appropriate. Debian bug ref: #239811 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1114: REVOKE done by non-privileged user claims success
The following bug has been logged online: Bug reference: 1114 Logged by: Oliver Elphick Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian Linux Description:REVOKE done by non-privileged user claims success Details: When REVOKE is used on an object for which the current user does not have GRANT privilege, the operation fails but "REVOKE" is returned as if it had succeeded: $ psql -U fred template1 template1=> revoke create on schema public from public; REVOKE (NB: this web interface at http://www.postgresql.org/bugform.html could do with Pg version options for 7.3.6, 7.4.1 and 7.4.2). ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1113: Default template databases grant CREATE to PUBLIC
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > The default should be for CREATE permissions on the public schema to be > revoked from PUBLICc. Not a chance. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1114: REVOKE done by non-privileged user claims success
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > When REVOKE is used on an object for which the current user does not have > GRANT privilege, the operation fails but "REVOKE" is returned as if it had > succeeded: Looking at the code, this seems to be intentional, because the privilege check is not made for revokes only for grants: if (stmt->is_grant && !pg_class_ownercheck(relOid, GetUserId()) && pg_class_aclcheck(relOid, GetUserId(), ACL_GRANT_OPTION_FOR(privileges)) != ACLCHECK_OK) aclcheck_error(ACLCHECK_NO_PRIV, ACL_KIND_CLASS, relvar->relname); Peter, do you remember why you did it that way? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1113: Default template databases grant CREATE to PUBLIC
Oliver Elphick <[EMAIL PROTECTED]> writes: > On Wed, 2004-03-24 at 15:55, Tom Lane wrote: >> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > The default should be for CREATE permissions on the public schema to be > revoked from PUBLICc. >> >> Not a chance. > But why? I didn't think this actually deserved any discussion, but if you insist: (a) This is a much bigger backwards-compatibility hit than you claim. All applications designed before 7.3 (and a lot of later ones) are going to assume that they can create objects without thinking about schema-level privileges. (b) There are several options for a DBA to change that behavior if he doesn't like it, ranging from dropping create on public, to dropping public completely, to actually solving the complained-of problem by revoking public usage rights on the function languages. He can also choose to do any of these things in template1 so that they automatically apply to later-created databases. So this is not a matter of lack of functionality, it is a question of whether to impose your notion of a good default behavior on everyone else. (c) The notion that forbidding function creation improves security is wrongheaded. Anyone who can issue arbitrary SQL commands can tie your database in knots anyway, for instance by requesting huge joins. Furthermore it is trivial to create a temporary function, eg joedb=> create temp table t(f1 int); CREATE TABLE joedb=> create function pg_temp_1.f1() returns int as 'select 1' language sql; CREATE FUNCTION so unless you propose to also disable temp-table creation by default, revoking object creation in PUBLIC isn't going to slow down an attacker at all. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
