Issue Details (XML | Word | Printable)

Key: CORE-3138
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Kuznetsov Eugene
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Internal error or crash occurs when accessing any MON$ table after altering its structure

Created: 17/Sep/10 07:23 PM   Updated: 19/Jul/15 09:19 PM
Component/s: Engine
Affects Version/s: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 3.0 Initial, 2.5 RC3, 2.5.0
Fix Version/s: 2.5.1, 2.1.5, 3.0 Alpha 1

Environment: Windows XP, Firebird-2.5.0.26084-0_Win32 shapshot


 Description  « Hide
Steps to reproduce
1.Create test base and ordinary user in isql
CREATE DATABASE "localhost:lab" USER "SYSDBA" PASSWORD "masterkey" PAGE_SIZE 8192 DEFAULT CHARACTER SET WIN1251;
CREATE USER TEST2 PASSWORD 'TEST2';
EXIT;
2. Succesfully change MON$ATTACHMENTS structure under TEST2
CONNECT "localhost:lab" USER "TEST2" PASSWORD "TEST2";
ALTER TABLE MON$ATTACHMENTS DROP MON$SERVER_PID;
EXIT;

Then SELECT * FROM MON$ATTACHMENTS from any connection returns
Statement failed, SQLSTATE = XX000
internal error
--
BR, Eugene

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Kuznetsov Eugene added a comment - 17/Sep/10 08:00 PM
Firebird-2.1.4.18347-0_Win32 snapshot is also undergone.

Such scenario crashes 2.1.4 (but not 2.5)

CONNECT "localhost:lab" USER "TEST2" PASSWORD "TEST2";
SELECT * FROM MON$ATTACHMENTS;
ALTER TABLE MON$ATTACHMENTS DROP MON$SERVER_PID;
SELECT * FROM MON$ATTACHMENTS;
SELECT MON$USER FROM MON$ATTACHMENTS;
ALTER TABLE MON$ATTACHMENTS DROP MON$USER;
SELECT * FROM MON$ATTACHMENTS;

Statement failed, SQLCODE = -902
Unable to complete network request to host "localhost".
...

Dmitry Yemanov added a comment - 14/Feb/11 08:27 AM
I cannot reproduce the crash on v2.1.4. For me, it throws the same "internal error" as v2.5.0.

Dmitry Yemanov added a comment - 14/Feb/11 08:31 AM
Sorry, now I see the crash.

Dmitry Yemanov added a comment - 14/Feb/11 10:36 AM
I have changed the ticket title to reflect only the subsequences (error/crash) of the altering the MON$ tables. Accessing them should behave similarly to regular tables, i.e. survive the structure changes properly. As for being allowed to alter system tables in general (not only MON$ tables are affected), please create a separate ticket.

Pavel Zotov added a comment - 19/Jul/15 09:19 PM
Only 3.0 has protection from any changes in structure of MON$ tables (even issued by SYSDBA).

As of 2.5.1 - 2.5.5, following test show that non-privileged user can drop fields from mon$attachments table:
===
set wng off;
connect '/:e25' user 'SYSDBA' password 'masterkey';
show version;
set list on; select mon$database_name from mon$database;

drop user tmp$c3138;
create user tmp$c3138 password '123';
revoke all on all from tmp$c3138;
commit;
show grants;

connect '/:e25' user 'TMP$C3138' password '123';

show table mon$attachments;
ALTER TABLE MON$ATTACHMENTS
  DROP MON$SERVER_PID
, DROP MON$STATE
, DROP MON$ATTACHMENT_NAME
, DROP MON$USER
, DROP MON$ROLE
, DROP MON$REMOTE_PROTOCOL
, DROP MON$REMOTE_ADDRESS
, DROP MON$REMOTE_PID
, DROP MON$CHARACTER_SET_ID
, DROP MON$TIMESTAMP
, DROP MON$GARBAGE_COLLECTION
, DROP MON$REMOTE_PROCESS
, DROP MON$STAT_ID
;
commit;

connect '/:e25' user 'TMP$C3138' password '123';
set list on;
set echo on;
show version;
show table mon$attachments;
select * from mon$attachments;
===

Output (sample for 2.5.5):
===
ISQL Version: WI-V2.5.5.26916 Firebird 2.5
Server version:
Firebird/x86/Windows NT (access method), version "WI-V2.5.5.26916 Firebird 2.5"
Firebird/x86/Windows NT (remote server), version "WI-V2.5.5.26916 Firebird 2.5/tcp (balaha)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.5.26916 Firebird 2.5/tcp (balaha)/P12"
on disk structure version 11.2

MON$DATABASE_NAME C:\FBTESTING\QA\FBT-REPO\TMP\E25.FDB

There is no privilege granted in this database
MON$ATTACHMENT_ID (RDB$ATTACHMENT_ID) INTEGER Nullable
MON$SERVER_PID (RDB$PID) INTEGER Nullable
MON$STATE (RDB$STATE) SMALLINT Nullable
MON$ATTACHMENT_NAME (RDB$FILE_NAME2) VARCHAR(255) CHARACTER SET UNICODE_FSS Nullable
MON$USER (RDB$USER) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
MON$ROLE (RDB$USER) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
MON$REMOTE_PROTOCOL (RDB$REMOTE_PROTOCOL) VARCHAR(10) CHARACTER SET ASCII Nullable
MON$REMOTE_ADDRESS (RDB$REMOTE_ADDRESS) VARCHAR(255) CHARACTER SET ASCII Nullable
MON$REMOTE_PID (RDB$PID) INTEGER Nullable
MON$CHARACTER_SET_ID (RDB$CHARACTER_SET_ID) SMALLINT Nullable
MON$TIMESTAMP (RDB$TIMESTAMP) TIMESTAMP Nullable
MON$GARBAGE_COLLECTION (RDB$SYSTEM_FLAG) SMALLINT Nullable
MON$REMOTE_PROCESS (RDB$FILE_NAME2) VARCHAR(255) CHARACTER SET UNICODE_FSS Nullable
MON$STAT_ID (RDB$STAT_ID) INTEGER Nullable
show version;
ISQL Version: WI-V2.5.5.26916 Firebird 2.5
Server version:
Firebird/x86/Windows NT (access method), version "WI-V2.5.5.26916 Firebird 2.5"
Firebird/x86/Windows NT (remote server), version "WI-V2.5.5.26916 Firebird 2.5/tcp (balaha)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.5.26916 Firebird 2.5/tcp (balaha)/P12"
on disk structure version 11.2
show table mon$attachments;
MON$ATTACHMENT_ID (RDB$ATTACHMENT_ID) INTEGER Nullable
select * from mon$attachments;

MON$ATTACHMENT_ID 4
===

So, no 'internal error' and no crashes. But MON$ table is unprotected.

The question is: can such protection be implemented in future sub-versions of FB 2.5 like in 3.0 ? (something like backport to 2.5.6 or so ?)