2015-02-02 5 views
0

SQL Server 2008R에서 이상한 버그 또는 동작이 발견되었습니다. 1 스키마에 대한 역할에 EXECUTE 권한을 부여하려고합니다. 그러나 시스템 개체를 볼 때 EXECUTE 사용 권한은 SYSTEM_TABLE sysallocunits으로 설정되어 있습니다. 다른 스키마에 권한을 부여하면 모든 것이 잘되고 사용 권한이 스키마에 설정됩니다. 내가 출력 다음 무엇입니까 쿼리를시스템 개체가 잘못된 GRANT를 반환합니다.

GRANT EXECUTE ON SCHEMA::Sync TO [app_TSSyncService_web_svc] 

select princ.name 
,  princ.type_desc 
,  perm.permission_name 
,  perm.state_desc 
,  perm.class_desc 
,  object_name(perm.major_id) 
from sys.database_principals princ 
left join 
     sys.database_permissions perm 
on  perm.grantee_principal_id = princ.principal_id 
WHERE princ.name = 'app_TSSyncService_web_svc' 

를 다음을 사용 : 나는 다른 역할이 스키마에 사용 권한을 부여 할 때

name type_desc permission_name state_desc class_desc (No column name) 
app_TSSyncService_web_svc DATABASE_ROLE EXECUTE GRANT SCHEMA sysallocunits 

같은 일이 발생합니다.

UPDATE 그냥 내 스키마 어떤 제안이 어떻게 하드 코딩하지 않고 무시하는 쿼리를 다시 작성할 수 있습니다 object_id의 동일한 sysallocunits을 가지고 있다는 것을 발견?

답변

2

아니요, 스키마에 schema_id이 있으며 sysallocunits의 경우 object_id과 같은 숫자 값이 사용됩니다.

개체가 아닌 다른 개체에 대한 사용 권한을 확인하는 쿼리가 잘못되었습니다. 스키마의 경우 object_idsys.objects에 포함된다고 가정하지 않고 major_idsys.database_permissions에서 schema_idsys.schemas으로 합치려는 것이 좋습니다.

내가 권한을 쿼리 할 수있는 클래스가 무엇인지 알지 못하기 때문에이 쿼리를 완전히 다시 작성하지 않으려 고합니다.

+0

귀하의 답변은 저에게 충분합니다. 쿼리를 다시 작성할 필요가 없습니다. 한 가지 더 궁금한 점이 있습니다. 다른 문제가 있습니까? 나는 스키마를 제외하고는이 상황을 일으킬 수있는 다른 무엇을 의미합니까? 레코드에 major_id가 0보다 크면 오브젝트가 아닐 수 있습니까? –