Subject | [firebird-support] Real problem with permissions |
---|---|
Author | Paul Hope |
Post date | 2008-06-30T09:41:30Z |
Hi
I have an increasingly embarrassing situation with one user at one customer
site. Unfortunately this person is a senior manager and the customer is
currently assessing its future software options!
Database object permissions appear to just stop working. I posted a message
about this a while back but got no responses - I therefore assume that
nobody else has experienced this problem - however I still need some
suggestions as to where to look.
FB V1.5.3.4870
Delphi 6 app
XP Pro and win2K clients
IBObjects 4.7.16
IBExpert 2008.02.19
The database has two logins SYSDBA and PAUL. All user security is handled
within the client app which logs in as PAUL. There are no roles defined
Typically what happens is that everything works OK, then one day I get a
call to say that an error has occurred 'No permission to access table xxx'.
I log on remotely using the app and get the same error. I go into IBExpert
and look at the permissions and they are all there. I delete them,
reinstate them, re-start the app and everything is OK.
This problem never occurs at logon where the app accesses the user table,
only when they access some other table later on.
the rdb$user_privileges typically looks like
RDB$USER - PAUL
RDB$GRANTOR - PAUL or SYSDBA (PAUL if created by the app, SYSDBA if I have
recreated it, - no direct effect on it working or not)
RDB$PRIVILEGE - RSIUD
RDB$GRANT_OPTION - sometimes null - possibly when created by app, 0 or 1 if
I have recreated.
RDB$RELATION_NAME
RDB$FIELD_NAME - null
RDB$USER_TYPE - 8
RDB$OBJECT_TYPE - 0 for tables
A very interesting thing was reported to me today. The user connected her
laptop to the internal network, started the app OK, tried to connect to a
newly created table and got the error. She then went to the computer that
ran the app to create the table, logged into the app and it worked fine. I
logged in remotely and got the error. I didn't think it made any
difference which client PC made the access or from where so this is very
surprising.
Any ideas I can follow up would be greatly appreciated
Regards
Paul
[Non-text portions of this message have been removed]
I have an increasingly embarrassing situation with one user at one customer
site. Unfortunately this person is a senior manager and the customer is
currently assessing its future software options!
Database object permissions appear to just stop working. I posted a message
about this a while back but got no responses - I therefore assume that
nobody else has experienced this problem - however I still need some
suggestions as to where to look.
FB V1.5.3.4870
Delphi 6 app
XP Pro and win2K clients
IBObjects 4.7.16
IBExpert 2008.02.19
The database has two logins SYSDBA and PAUL. All user security is handled
within the client app which logs in as PAUL. There are no roles defined
Typically what happens is that everything works OK, then one day I get a
call to say that an error has occurred 'No permission to access table xxx'.
I log on remotely using the app and get the same error. I go into IBExpert
and look at the permissions and they are all there. I delete them,
reinstate them, re-start the app and everything is OK.
This problem never occurs at logon where the app accesses the user table,
only when they access some other table later on.
the rdb$user_privileges typically looks like
RDB$USER - PAUL
RDB$GRANTOR - PAUL or SYSDBA (PAUL if created by the app, SYSDBA if I have
recreated it, - no direct effect on it working or not)
RDB$PRIVILEGE - RSIUD
RDB$GRANT_OPTION - sometimes null - possibly when created by app, 0 or 1 if
I have recreated.
RDB$RELATION_NAME
RDB$FIELD_NAME - null
RDB$USER_TYPE - 8
RDB$OBJECT_TYPE - 0 for tables
A very interesting thing was reported to me today. The user connected her
laptop to the internal network, started the app OK, tried to connect to a
newly created table and got the error. She then went to the computer that
ran the app to create the table, logged into the app and it worked fine. I
logged in remotely and got the error. I didn't think it made any
difference which client PC made the access or from where so this is very
surprising.
Any ideas I can follow up would be greatly appreciated
Regards
Paul
[Non-text portions of this message have been removed]