[CBRD-25580] Grant/Revoke re-define (11.4) #1944
Conversation
| =================================================== | ||
| owner.name grants | ||
| U1 null | ||
| U2 |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
| =================================================== | ||
| owner.name grants | ||
| U1 null | ||
| U2 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
|
|
||
| =================================================== | ||
| owner.name grants | ||
| U1 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
|
|
||
| =================================================== | ||
| owner.name grants | ||
| U1 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
|
|
||
| =================================================== | ||
| owner.name grants | ||
| U1 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
|
|
||
| =================================================== | ||
| owner.name grants | ||
| U1 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
|
|
||
| =================================================== | ||
| owner.name grants | ||
| U1 null |
There was a problem hiding this comment.
@jongmin-won
예상 답지로 주셨던 내용에는 grants에 값이 출력되었어야 합니다만 null이 출력 됐습니다.
이는 CBRD-25486 issue와 관련이 있다고 판단됩니다.
검토 한번 부탁드립니다.
There was a problem hiding this comment.
이 내용은 CBRD-25486하고 관련이 없습니다.
이는 jdbc driver의 구현상의 문제로 db_authorization 테이블의 grants column은 출력되지 않습니다.
swi0110
requested review from
tw-kang and
bagus-kim
and removed request for
hiclass
| select owner.name, grants from db_authorization where owner.name = 'U1' order by owner.name; | ||
|
|
||
| evaluate 'u1 re-grant to dba.tbl'; | ||
| GRANT SELECT ON dba.tbl TO u1; |
There was a problem hiding this comment.
해당 TC는 이전에 "WITH GRANT OPTION" 구문으로 처리를 하였고,
"WITH GRANT" 구문을 제외하고 재실행 시에 "is_grantable"이 그대로 유지되는가를 확인하는 테스트입니다.
사용자 관점으로 본다면,
해당 구문이 정상실행되면, "WITH GRANT"가 적용되지 않는 형태로 적용된다고 생각할수 있을것 같습니다.
해당 구문으로 처리되는 내용이 없고, 해당구문을 적용하기 위해서는 revoke 명령으로 처리해야 함으로, 에러메세지를 출력해 주는게 좋을것 같습니다.
개발팀과 논의해보고, 다른SQL문 등의 처리방법( ALTER TABLE 등)과의 일관성 측면 등과 함께 검토하고, 검토결과를 해당 이슈에 작성하는게 좋을것 같습니다.
There was a problem hiding this comment.
기존에 CUBRID 동작이 '이미 권한이 부여된 계정에 동일한 권한을 다시 부여할 경우 no operation으로 동작'하도록 구현이 되어 있습니다.
말씀하신 부분도 no operation으로 동작하는게 사용자 입장에서 혼란이 될 수는 있겠으나, 일관성 측면에서는 문제가 없을 것 같습니다.
@jongmin-won
확인하시고 의견 부탁드립니다.
There was a problem hiding this comment.
제 생각에도, 일관성을 고려했을 때 에러 메시지 보다 no operation 이 맞다고 생각 됩니다.
과거 CUBRID 9.2 버전부터, WITH GRANT OPTION을 포함하여 권한을 부여한 후 동일한 GRANT 구문에서 WITH GRANT OPTION을 제외하고 재실행할 경우, 에러가 발생하지 않았습니다.
이때, db_authorization 카탈로그의 grants에 저장된 mask 값은 WITH GRANT OPTION 가 가능한 상태로 유지되지만,
db_auth 카탈로그의 is_grantable 값은 'YES' → 'NO'로 변경되는 버그가 있었습니다.
추가로, CBRD-25596 이슈의 comment에서 Oracle을 테스트 한 결과, CUBRID와 마찬가지로 에러 메시지 없이 no operation으로 처리되는 것을 확인했습니다. (벤치마킹 목적으로 테스트 수행)
|
|
||
|
|
||
| evaluate 'u1 grant to dba.tbl (with grant option)'; | ||
| GRANT SELECT ON dba.tbl TO u1 WITH GRANT OPTION; |
There was a problem hiding this comment.
u1 계정은 dba로부터 select에 대해서만 권한을 부여하도록 권한을 받았습니다.
u2계정을 생성해서 u1계정이 u2에게 select 권한을 부여할 수 있는지 확인 ( 기존 TC가 있으면 생략 )
u1 계정이 u2에게 insert, alter 등의 권한을 부여하려고 할때 에러가 발생하는지 확인 ( 기존 TC가 있으면 생략 )
There was a problem hiding this comment.
해당 내용은 cbrd_25582.sql에 테스트 시나리오로 추가하도록 하겠습니다.
| GRANT SELECT ON dba.tbl TO u1 WITH GRANT OPTION; | ||
| GRANT INSERT ON dba.tbl TO u1; | ||
|
|
||
| select * from db_auth where grantee_name != 'PUBLIC' order by grantor_name; |
There was a problem hiding this comment.
order by 조건이 grantor_name이여서, 출력결과 순서가 바뀔수도 있습니다.
grantor_name, auth_type 순으로 처리하는게 좋을것 같습니다.
|
|
||
|
|
||
| evaluate 'u1 re-grant to dba.tbl'; | ||
| GRANT SELECT, INSERT ON dba.tbl TO u1; |
There was a problem hiding this comment.
위 개발팀 논의 내용과 동일하게 검토해 주세요.
|
|
||
| evaluate 'u1 grant to dba.tbl (with grant option)'; | ||
| GRANT SELECT ON dba.tbl TO u1 WITH GRANT OPTION; | ||
| GRANT INSERT ON dba.tbl TO u1; |
There was a problem hiding this comment.
select 권한은 다른 유저에게 권한을 부여할 수 있고,
insert 권한은 다른 유저에게 권한 부여가 불가할 것 같습니다.
해당 TC 추가를 검토해 주세요. ( 관련 TC가 존재한다면 생략해도 됩니다. )
There was a problem hiding this comment.
권한을 받지 않은 권한을 다른 계정에 권한을 부여하는 경우에 대한 시나리오를 cbrd_25582.sql에 추가하도록 하겠습니다.
| select * from db_auth where grantee_name != 'PUBLIC' order by grantor_name; | ||
|
|
||
| select owner.name, grants from db_authorization where owner.name = 'U1' order by owner.name; | ||
|
|
There was a problem hiding this comment.
CBRD-25580 이슈의 "1-3"의 sub 이슈가 CBRD-25596 이슈입니다.
"1-3"의 내용에 "WITH GRANT OPTION을 회수하려면, 먼저 권한을 REVOKE한 후 다시 권한을 부여해야 합니다."라는 내용이 있습니다.
"with grant"를 주고, revoke하고 권한을 추가하는 TC는 추가에 대해서 검토해 주세요. ( 다른 TC에서 검증이 되는지 .. )
There was a problem hiding this comment.
revoke하는 시점에서 db_auth 테이블에서 값이 delete됩니다.
제 생각에 개별 테스트 시나리오에서 검증이 되고 있다고 생각됩니다.
|
|
||
|
|
||
| evaluate 'case 1: execute to revoke on dba'; | ||
| GRANT SELECT ON u1.TBL TO dba WITH GRANT OPTION; |
There was a problem hiding this comment.
CBRD-25580 이슈의 "3-3. DBA에게 권한을 부여할 수 없도록 검토" 내용의 TC입니다.
이슈 설명: DBA는 슈퍼유저이므로, 다른 사용자가 DBA에게 권한을 부여하는 행위는 부자연스럽게 보일 수 있습니다.
기대 동작: DBA에게 권한을 부여하려고 할 때, 소유자에게 권한을 부여하는 경우와 동일하게 에러 메시지를 출력해야 합니다.
해당 이슈를 진행할것인지 확인하고, 관련내용을 주석으로 작성해 주세요.
또는 dba에게 권한부여가 아닌 다른계정으로 변경을 검토해 주세요.
There was a problem hiding this comment.
CBRD-25580 이슈의 '3. 향후 논의가 필요한 스펙 변경'에 대한 내용은 최소 guava 이후에 논의가 필요한 내용을 적어둔 것 입니다.
또한 dba가 dba에게 권한을 부여할 때 error가 발생한다면 다른 계정에서 dba에게 권한을 부여할 때도 동일하게 error가 발생할 것이기 때문에 검증에 문제가 없다고 판단 했습니다.
또한 해당 내용들은 '반드시 수정이 필요'한 것이 아니라 '향후 고려해볼 필요가 있다'정도로 생각해주시면 됩니다.
@jongmin-won
CBRD-25580 이슈의 '3. 향후 논의가 필요한 스펙 변경'에 대한 내용을 논의할 시점을 명시해주시면 좋을 것 같습니다.
There was a problem hiding this comment.
@swi0110
네, CBRD-25580 이슈의 '3. 향후 논의가 필요한 스펙 변경'에 대한 내용은 guava 에서 PM팀과의 논의를 거쳐 스펙에 반영될 계획입니다.
아래 3가지 사항 모두를 반영할지, 일부만 반영할지는 논의 결과에 따라 결정될 예정입니다.
3-1. 권한 부여 시 No Operation 또는 오류 처리 방식을 ORACLE과 동일하게 변경 검토
3-2. 권한 해지 시 DBA가 모든 사용자의 권한을 해지할 수 있도록 검토
3-3. DBA에게 권한을 부여할 수 없도록 검토
There was a problem hiding this comment.
3-1과 3-2는 추가 개발사항이 없고, 개발에 반영되어 있는것으로 생각했습니다.
따라서 3-3도 개발된 것으로 생각했습니다.
@jongmin-won
3-1, 3-2와 관련해서 추가로 스펙논의가 필요한 내용이 무엇인지 예시가 있나요?
@swi0110
현재, 개발팀에서 "3-3"에 대한 부분이 개발 안되었고, 향후 개발여부를 알 수 없다면...
해당 부분에 대한 TC를 모두 포함하고 향후에 답지만 변경하는 형태로 가는게 좋을지
아니면, 향후 개발여부를 모르니깐.. 관련 이슈에 대한 TC를 배제하고 TC를 작성하는게 좋을지
어떤게 더 좋은가요?
현재는 일부만 적용한 상황으로 보여지네요.
해당 이슈에서 guava 이후에 논의가 필요한 상황에 대한 전체 TC를 작성하거나..
아니면, guava 이후의 이슈는 작성을 안하는 것이, 좋을것 같습니다.
There was a problem hiding this comment.
@kwonhoil
제 생각에는 '해당 부분에 대한 TC를 모두 포함하고 향후에 답지만 변경하는 형태'가 알맞다고 생각됩니다.
현재 동작을 이 tc에서 검증하고, 향후 스펙 재논의 및 수정을 하게 된다면, 답지를 수정하는 식으로 대응하는게 맞을 것 같습니다.
There was a problem hiding this comment.
3-1 예제
- NO-OP 동작 예시
call login('dba','') on class db_user;
grant select on u1.tbl to u1;
/*
- dba가 grant를 수행할 때, 소유자가 권한을 부여하는 것으로 동작합니다.
- 즉, u1 -> u1 에게 권한을 부여하는 것과 동일 합니다.
*/
call login('u1','') on class db_user;
grant select on u1.tbl to u1;- ERROR 동작 예시
call login('u1','') on class db_user;
grant select on u1.tbl to u2;
grant select on u1.tbl to u3;
call login('u2','') on class db_user;
grant select on u1.tbl to u2;
/*
1. 스펙 논의 후 해당 Case를 NO-OP -> ERROR 로 변경
2. 현재 CUBRID 에서는 NO-OP로 동작합니다.
- u2 사용자는 u1.tbl의 권한이 있으므로, 자기자신에게 다시 부여하는 행위는 NO-OP 입니다.
*/
call login('u3','') on class db_user;
grant select on u1.tbl to u3;
/*
1. 스펙 논의 후 해당 Case를 NO-OP -> ERROR 로 변경
2. 현재 CUBRID 에서는 NO-OP로 동작합니다.
- u3 사용자는 u1.tbl의 권한이 있으므로, 자기자신에게 다시 부여하는 행위는 NO-OP 입니다.
*/3-2 예제
- 아래 revoke 구문의 예제에서 현재 CUBRID와 Oracle는 revoke가 실패합니다.
- 실패 이유 : revoke는 권한을 부여한 사용자(grantor)와 권한을 회수하려는 사용자(login_user)가 동일한 경우에만 실행이 가능합니다.
- 이와 관련하여, 팀 회의에서 DBA는 최고 관리자 역할을 수행하므로 모든 사용자의 권한을 회수할 수 있도록 수정하는 방안에 대한 아이디어가 나와 향후 PM팀 과 논의가 필요합니다.
call login('dba','') on class db_user;
grant select on u1.tbl to u2 with grant option;
call login('u2','') on class db_user;
grant select on u1.tbl to u3 with grant option;
/*
||grantor || grantee ||
| u1 | u2 |
| u2 | u3 |
*/
call login('dba','') on class db_user;
revoke select on u1.tbl from u3;
/*
--revoke 성공
*/
There was a problem hiding this comment.
이와 관련하여, 팀 회의에서 DBA는 최고 관리자 역할을 수행하므로 모든 사용자의 권한을 회수할 수 있도록 수정하는 방안에 대한 아이디어가 나와 향후 PM팀 과 논의가 필요합니다.
저는 동의 합니다. DBA가 또는 DBA GROUP 내의 유저가 특정 유저의 비밀번호 파악을 못하고 있을 수도 있으며 해당 상황에 DBA(incl DBA group member)가 컨트롤 하는 것이 맞다고 생각됩니다.
| create user u4; | ||
| create user u5; | ||
|
|
||
| create table u1.tbl (col1 int); |
There was a problem hiding this comment.
3개 sql TC중에서 각각 다른 오브젝트로 하는게 좋을것 같습니다.
예시)
table
view table
procedure
| U1 U2 CLASS tbl U1 SELECT YES | ||
| U2 U3 CLASS tbl U1 SELECT YES | ||
| U3 U4 CLASS tbl U1 SELECT YES | ||
| U4 U5 CLASS tbl U1 SELECT YES |
There was a problem hiding this comment.
번호1
db_auth 테이블은 뷰테이블입니다.
u4 계정으로 접속햇을때 u4 계정에 대한부분만 조회되어야 할 것 같은데요.
권한 관련된 모든 정보가 조회되고 있습니다.
개발팀과 협의하고, 협의결과 이슈에 작성해 주세요.
There was a problem hiding this comment.
시스템 테이블은 모든 계정이 접근 가능합니다.
조회가 가능하다고해서 시스템 테이블을 핸들링할 수 있는 것은 아니니, 크게 문제가 되지 않을 것 같습니다.
또한 db_auth 테이블 조회시 전체 계정의 내용이 조회 되는 것은 CUBRID의 legacy issue에 해당하며, 이번 issue에서 협의할 내용은 아니라고 생각합니다.
@jongmin-won
이와 관련해서 향후 수정 계획이 있는지, 만약 스펙 변경을 요청했을 때 예상 소요시간에 대한 답변 부탁드립니다.
There was a problem hiding this comment.
@swi0110
WITH GRANT OPTION으로 전파된 권한이 전부 다 보여지는 것이 맞다고 생각 됩니다.
만약, dba 에서 아래와 같이 db_auth 조회 결과가 있을 경우 u4 에서 db_auth 를 조회하면 아무런 결과가 나오지 않게 됩니다.
- dba 에서 db_auth 조회
select * from db_auth where grantee_name != 'PUBLIC' order by grantor_name;
/*
grantor_name grantee_name object_type object_name owner_name auth_type is_grantable
==========================================================================================================================================================
'U1' 'U2' 'CLASS' 'tbl' 'U1' 'SELECT' 'YES'
'U2' 'U3' 'CLASS' 'tbl' 'U1' 'SELECT' 'YES'
*/- u4 에서 db_auth 조회
select * from db_auth where grantee_name != 'PUBLIC' order by grantor_name;
/*
There are no results.
0 row selected.
*/
| evaluate 'connect to u2'; | ||
| call login('u2','') on class db_user; | ||
| evaluate 'ERROR: Cannot issue GRANT/REVOKE to owner of a class'; | ||
| GRANT SELECT ON u1.TBL TO u1 WITH GRANT OPTION; |
There was a problem hiding this comment.
접속계정으로 권한 부여하는 경우에 에러가 발생하는지 정상처리되는지 확인
GRANT SELECT ON u1.TBL TO u2 WITH GRANT OPTION;
아래 TC에도 동일하게 반영
There was a problem hiding this comment.
u1 계정에서 'GRANT SELECT ON u1.TBL TO u1 WITH GRANT OPTION;' 를 수행하는 시나리오와
u2 계정에서 'GRANT SELECT ON u1.TBL TO u2 WITH GRANT OPTION;' 를 수행하는 시나리오를 추가했습니다.
덧붙혀서 자기 자신에게 권한을 부여하는 경우, no operation으로 처리되어, 쿼리 수행시 정상 동작으로 처리됩니다.
또한 db_auth에는 해당 내용이 추가되지 않습니다.
|
|
||
| evaluate 'connect to u1, success'; | ||
| call login('u1','') on class db_user; | ||
| GRANT SELECT ON dba.tbl TO u1; |
There was a problem hiding this comment.
"GRANT SELECT ON dba.tbl TO u1;"
"No-Operation"으로 동작하는게 좋을지, 에러를 발생하는게 좋을지에 대한 검토가 필요합니다. ( 사용자 관점에서 )
CBRD-25585 내용
추가 테스트 2) 소유자가 SELECT WITH GRANT OPTION 권한을 부여하고, 부여 받은 사용자가 자신에게 권한을 부여하는 경우
사용자 u1이 자신에게 권한을 부여할 때 No-Operation으로 동작하여야 합니다.
There was a problem hiding this comment.
말씀하신 '추가 테스트2'에 대한 내용이 해당 시나리오라고 생각됩니다.
(dba가 u1에게 dba.tbl의 select with grant option 권한 부여 -> u1 접속 후, u1 자신에게 dba.tbl의 select 권한 부여)
혹시 제가 잘못 이해한 내용이 있다면 답변 부탁드립니다.
@jongmin-won
이미 부여받은 권한이 있는 경우, 기존에는 no operation으로 동작했지만, error로 처리하면 어떨지에 대한 의견입니다.
확인 및 답변 부탁드립니다.
There was a problem hiding this comment.
해당 부분은 CBRD-25580 이슈의 '3-1. 권한 부여 시 No Operation 또는 오류 처리 방식을 ORACLE과 동일하게 변경 검토' 에 대한 내용으로 확인 됩니다.
해당 스펙 논의는 guava 에서 PM팀과의 논의를 생각 하고 있습니다.
현재 '코드 수정 전(9.2 ~ 11.3v)' 과 '수정 후(fig-cake)' 의 스펙은 아래와 같습니다.
1.코드 수정 전(9.2 ~ 11.3v)
- login_user 와 grant 구문의 to user가 같으면 무조건 no operation으로 동작 합니다.
2.수정 후(fig-cake)
- login_user 와 grant 구문의 to user가 같은 경우 아래 2가지 조건을 확인하도록 추가 됐습니다.
-- login_user가 grant 권한을 부여 받은 경우 : no operation 로 동작
-- login_user가 grant 권한을 부여 받지 않는 경우 :error 로 동작
위와 같이 기준을 잡은 이유는 CBRD-25607 이슈의 '변경 기준'의 1번과 동일 합니다.
- Grant 권한을 부여받지 않은 사용자는 권한을 부여하거나 회수할 수 없다.
swi0110
force-pushed
the
add_CBRD-25580_11.4
branch
from
0fb92af to
b588bc1
Compare
swi0110
changed the title
|
Changed base branch |
Refer to http://jira.cubrid.org/browse/CBRD-25580
Sub-task issue