Subject | Server abort and security.fdb changes |
---|---|
Author | Geoff Worboys |
Post date | 2005-02-13T01:45:59Z |
Hi all,
FB v1.5.2.
I have been trying to use some of Ivan Prenosil's ideas for
enhancing the security of the security.fdb, but seem to
have run into a problem.
I create this view as a replacement for the dropped USERS
table:
CREATE VIEW USERS AS
SELECT *
FROM USERS_ADMIN
WHERE USER = 'SYSDBA' OR
USER = USER_NAME
(USER = '' AND (LogLoginAttempt(USER_NAME) = 0));
It works fine when used in as a separate database (not the
actual security database). I created a simple variation:
CREATE VIEW USERS_TEST AS
SELECT *
FROM USERS_ADMIN
WHERE (LogLoginAttempt(USER_NAME) = 0);
to be sure that the LogLoginAttempt UDF was working and did
not cause exceptions (even under readonly transactions).
However when I install the database with the first view as
the security database, and then try to connect (as SYSDBA)
the server aborts with the firebird.log message:
...\fbserver.exe: terminated abnormally (3221225477)
Note that this view:
CREATE VIEW USERS AS
SELECT *
FROM USERS_ADMIN
WHERE USER = 'SYSDBA' OR
USER = USER_NAME OR
USER = '';
seems to work in all cases. So the problem would appear to
be related to the use of the UDF, but the UDF works fine on
outside the specific security database situation.
I was originally calling the UDF from a stored procedure,
following Ivan's example. But have gradually cut things back
to the above view in order to try and isolate the problem.
Note: Using a UDF because Ivan noted that FB v1.5.2 uses a
readonly transaction, thus any logging must be done via a
UDF rather than via an external table or whatever.
To be extra sure it was not just my UDF I replaced it with
a call to "BIN_AND(1,1) = 1" - you cant get a UDF that is much
simpler than that. This caused exactly the same server abort.
I was not sure whether to send this here or to the devel
list. Starting here to see if anyone has managed to get
anything similar working under FB v1.5.2. Given my record
over the last few days I am not convinced that its a bug,
perhaps its just me. :-(
--
Geoff Worboys
Telesis Computing
FB v1.5.2.
I have been trying to use some of Ivan Prenosil's ideas for
enhancing the security of the security.fdb, but seem to
have run into a problem.
I create this view as a replacement for the dropped USERS
table:
CREATE VIEW USERS AS
SELECT *
FROM USERS_ADMIN
WHERE USER = 'SYSDBA' OR
USER = USER_NAME
(USER = '' AND (LogLoginAttempt(USER_NAME) = 0));
It works fine when used in as a separate database (not the
actual security database). I created a simple variation:
CREATE VIEW USERS_TEST AS
SELECT *
FROM USERS_ADMIN
WHERE (LogLoginAttempt(USER_NAME) = 0);
to be sure that the LogLoginAttempt UDF was working and did
not cause exceptions (even under readonly transactions).
However when I install the database with the first view as
the security database, and then try to connect (as SYSDBA)
the server aborts with the firebird.log message:
...\fbserver.exe: terminated abnormally (3221225477)
Note that this view:
CREATE VIEW USERS AS
SELECT *
FROM USERS_ADMIN
WHERE USER = 'SYSDBA' OR
USER = USER_NAME OR
USER = '';
seems to work in all cases. So the problem would appear to
be related to the use of the UDF, but the UDF works fine on
outside the specific security database situation.
I was originally calling the UDF from a stored procedure,
following Ivan's example. But have gradually cut things back
to the above view in order to try and isolate the problem.
Note: Using a UDF because Ivan noted that FB v1.5.2 uses a
readonly transaction, thus any logging must be done via a
UDF rather than via an external table or whatever.
To be extra sure it was not just my UDF I replaced it with
a call to "BIN_AND(1,1) = 1" - you cant get a UDF that is much
simpler than that. This caused exactly the same server abort.
I was not sure whether to send this here or to the devel
list. Starting here to see if anyone has managed to get
anything similar working under FB v1.5.2. Given my record
over the last few days I am not convinced that its a bug,
perhaps its just me. :-(
--
Geoff Worboys
Telesis Computing