Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal error or crash occurs when accessing any MON$ table after altering its structure [CORE3138] #3515

Closed
firebird-automations opened this issue Sep 17, 2010 · 14 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Kuznetsov Eugene (eugene)

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

Commits: b1a7412 f2c890e e65cc13

@firebird-automations
Copy link
Collaborator Author

Commented by: Kuznetsov Eugene (eugene)

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".
...

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

security: Developers [ 10012 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I cannot reproduce the crash on v2.1.4. For me, it throws the same "internal error" as v2.5.0.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Sorry, now I see the crash.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Version: 2.5.0 [ 10221 ]

Version: 3.0 Initial [ 10301 ]

Version: 2.1.3 [ 10302 ]

Version: 2.1.2 [ 10270 ]

Version: 2.1.1 [ 10223 ]

Version: 2.1.0 [ 10041 ]

summary: Unprivileged user can change mon$-tables structure => Internal error or crash occurs when accessing any MON$ table after altering its structure

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 2.5.1 [ 10333 ]

Fix Version: 2.1.5 [ 10420 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: In Progress [ 3 ] => Open [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

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 ?)

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment