Thread: Heavy security bug in 7.2.2-16?

Dear list,

as far as I have made my experiences in version 7.2.2-16 (SuSE Linux 8.1) it
is possible for *every* user which is able to create a database and/or is
able to create new users to delete a database from every other user. I did
not find any hints in the FAQ or archives.

Especially when the superuser postmaster creates a database, e.g. test, a
normal user although he is *not* the owner, if it is not denied that he can
create new databases AND that he can create new users, can delete the
database even if there are restrictions made on a table within the database
by the owner (GRANT).

I cannot find the mistake I have made, since in an older version this problem
did not occur. Thanks a lot.

Heiko
--
Heiko Schroeder
Ahrensburg, Germany
http://home.foni.net/~heikos

Heiko Schroeder <heikos@foni.net> writes:
> Especially when the superuser postmaster creates a database, e.g. test, a
> normal user although he is *not* the owner, if it is not denied that he can
> create new databases AND that he can create new users,

A user that can create new users is a superuser; there is no distinction
in Postgres.  As a superuser, there are no protection restrictions on
him.

            regards, tom lane

I wonder how I call nextval('mysequence') programmatically, preferably
in Java. But if you could give an example in another language, I'd
probably figure it out as well.

Is it the same as a call to a stored procedure? Or is just a normal SQL
statement?

Thanks,
r.

I believe it is not possible yet in postreSQL, but in case it is what
would be the equivalent of the following Oracle statement (assuming
current myfield size to be 10 bytes (of type char)):
ALTER TABLE mytable MODIFY (myfield CHAR(12));

If it's currently not supported is there a way to submit an RFE?

Thanks,
r.

El dom, 29-12-2002 a las 14:35, Reshat Sabiq escribió:
> I believe it is not possible yet in postreSQL, but in case it is what
> would be the equivalent of the following Oracle statement (assuming
> current myfield size to be 10 bytes (of type char)):
> ALTER TABLE mytable MODIFY (myfield CHAR(12));
>
> If it's currently not supported is there a way to submit an RFE?

    It's not supported. You can instead create a new table with the field
already as you want it to be, and transfer data, as explained in [1].

    Another possible way, if you are using PostgreSQL 7.3, it already
supports dropping columns so you can create a new column myfield_temp as
char(12), copy values from myfield, drop myfield and rename myfield_temp
to myfield. You should keep in mind that default and NOT NULL are not
supported in ADD COLUMN and you should use SET DEFAULT or SET NOT NULL
aftewards as required.

[1] http://techdocs.postgresql.org/techdocs/updatingcolumns.php

    Regards,
--
Alberto Caso Palomino
Adaptia Soluciones Integrales
http://www.adaptia.net
alberto.caso@adaptia.net

I saw on a website an advice, that for features like referential
integrity etc. postgres tables need to be of type Innodb. Isn't innodb
something that MySQL needs.
I've been assuming that the advanced nice features (transactions, etc.)
are built-in in postgres and are enabled by default. Am I right?

Sincerely,
r.

Hi,

* Reshat Sabiq <sabiq@purdue.edu> [2002-12-30 10:49]:
>I saw on a website an advice, that for features like referential
>integrity etc. postgres tables need to be of type Innodb. Isn't innodb
>something that MySQL needs.

Referentials work just fine without any new table type, and yes,
InnoDB is something I heard in connection with MySQL.

Don't visit that website again for advice.


>I've been assuming that the advanced nice features (transactions, etc.)
>are built-in in postgres and are enabled by default. Am I right?

I sure hope so.


Thorsten
--
Golly, I'd hate to have a kid like me!
    - Calvin