Hi Park,
There is a defect in cubrid: when drop a user, don’t do anything about authorizations, so in tables _db_auth , db_auth, db_authorization, there will have authorization information about the deleted users. It’s ok in cubrid .
In cluster ,because global users will reuse the same oids, drop a global user just change its name, and it will be used later, so old authorization information will have influence when a new global user use the same oid .
Like this: local user1 ,user2 and user3, user1 create a table xx, and grant user2 authorizations like select and update with grant option, so user2 can grant select and update authorizations to user3 ,it just grant update. Now in _db_auth, is like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 user2 xx update 1
User2 user3 xx update 0
When drop user2,_db_auth will like :
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 null xx update 1
null user3 xx update 0
it’s be ok when users are local just as in cubrid.
But in cluster ,for the reserved global user pool solution, when drop a global user ,just change it’s name ,oid is same ,so above will like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 Reserved_name xx update 1
Reserved_name user3 xx update 0
Attation:use user name for demonstration, in cluster ,will be oids.
So something must be done about authorization. So as global users, when drop one, will clean the authorization information, making the global user oid freed don’t have any authorizations. That is that the oid of the deleting global user don’t be grantee attribute in _db_auth, db_auth, db_authorization.
I think may achieving it by a delete operation, it will compile in one node and execute in all nodes.
How do you think about it, and do you have better solution?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok… I can understand what happens when the global user is dropped.. but sorry I cannot understand what you want to do.
Do you mean that the current CUBRID does not delete the related _db_auth entries when dropping a (local) user, and it is defect(bug)…, right?
Thus, are you suggesting to fix the bug for the CUBRID Cluster version?
If you are, it is absolutely good.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now the work is to clean the authorization information when dropping a global user,so later creating a new global user with the same oid will have no authorizations. My solutions is to delete it directly, and do you have another solution?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Li Lin suggest , when drop global user, we add to delete the rows in _db_auth. such as when drop Global_user1.
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 Global_user1 xx update 1
Global_user1 user3 xx update 0
we just delete the rows which grantee is Global_user1. we do not delete the rows which Grantor is Global_user1.
so, after drop Global_user1. The _db_auth will be like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
Global_user1 user3 xx update 0
drop local user is not changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Park,
There is a defect in cubrid: when drop a user, don’t do anything about authorizations, so in tables _db_auth , db_auth, db_authorization, there will have authorization information about the deleted users. It’s ok in cubrid .
In cluster ,because global users will reuse the same oids, drop a global user just change its name, and it will be used later, so old authorization information will have influence when a new global user use the same oid .
Like this: local user1 ,user2 and user3, user1 create a table xx, and grant user2 authorizations like select and update with grant option, so user2 can grant select and update authorizations to user3 ,it just grant update. Now in _db_auth, is like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 user2 xx update 1
User2 user3 xx update 0
When drop user2,_db_auth will like :
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 null xx update 1
null user3 xx update 0
it’s be ok when users are local just as in cubrid.
But in cluster ,for the reserved global user pool solution, when drop a global user ,just change it’s name ,oid is same ,so above will like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 Reserved_name xx update 1
Reserved_name user3 xx update 0
Attation:use user name for demonstration, in cluster ,will be oids.
So something must be done about authorization. So as global users, when drop one, will clean the authorization information, making the global user oid freed don’t have any authorizations. That is that the oid of the deleting global user don’t be grantee attribute in _db_auth, db_auth, db_authorization.
I think may achieving it by a delete operation, it will compile in one node and execute in all nodes.
How do you think about it, and do you have better solution?
Ok… I can understand what happens when the global user is dropped.. but sorry I cannot understand what you want to do.
Do you mean that the current CUBRID does not delete the related _db_auth entries when dropping a (local) user, and it is defect(bug)…, right?
Thus, are you suggesting to fix the bug for the CUBRID Cluster version?
If you are, it is absolutely good.
Thanks.
Now the work is to clean the authorization information when dropping a global user,so later creating a new global user with the same oid will have no authorizations. My solutions is to delete it directly, and do you have another solution?
Thanks.
How can I have another and better solution? Go as you planned if your team discussed enough about this issue.
Ok,Thanks.
2011-05-24 16:36:53 CST
I want to add discription about it.
Li Lin suggest , when drop global user, we add to delete the rows in _db_auth. such as when drop Global_user1.
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
User1 Global_user1 xx update 1
Global_user1 user3 xx update 0
we just delete the rows which grantee is Global_user1. we do not delete the rows which Grantor is Global_user1.
so, after drop Global_user1. The _db_auth will be like:
Grantor grantee class_of auth_type is_grantable
User1 user2 xx select 1
Global_user1 user3 xx update 0
drop local user is not changed.