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
Comments
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"; Statement failed, SQLCODE = -902 |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovsecurity: Developers [ 10012 ] => |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Commented by: @dyemanov I cannot reproduce the crash on v2.1.4. For me, it throws the same "internal error" as v2.5.0. |
Commented by: @dyemanov Sorry, now I see the crash. |
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. |
Modified by: @dyemanovVersion: 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 |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
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; drop user tmp$c3138; connect '/:e25' user 'TMP$C3138' password '123'; show table mon$attachments; connect '/:e25' user 'TMP$C3138' password '123';
|
Modified by: @pavel-zotovQA Status: No test |
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
The text was updated successfully, but these errors were encountered: