|
|
Posted by Hugo Kornelis on 10/22/06 21:14
On 15 Oct 2006 23:34:03 -0700, Amber wrote:
>In step 9 and 11,I also choose the CONTROL permission for deny .Later I
>found if I uncheck the CONTROL's deny permission checkbox(let three
>options empty),then user guxiaobo can select the tables.
>
>Here comes the question,how the control permission applys to table
>object?
Hi Amber,
Yes, this is expected behaviour.
To understand the security architecture, you must be aware that denying
pernmission is not the same as not granting permission. Not explicitly
granting a permission to a user is enough to make sure that he or she
won't be allowed that action. Explicitly denying a permission is a more
fierce step - you are basically saying that this user really, really,
really should not have this access. Ever. And no amount of granting can
reverse that.
In other words: a DENY will always override a GRANT.
The Books Online page about DENY Object Permissions (see
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/0b8d3ddc-38c0-4241-b7bb-ee654a5081aa.htm)
has a nice table that shows how various object-level permissions inherit
from schema level permissions. You'll see that object-level SELECT
inherits from schema-level SELECT. And the similar table in the page
about DENY Schema Permissions
(ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/300a67c4-d226-4653-9e9f-7ae4d53fcf33.htm)
shows that schema-level SELECT inherits from schema-level SELECT. So
these two steps combined explain the the SELECT was disalllowed because
the explicit object-level ALLOW SELECT was overriden by the (doubly
inherited) DENY SELECT.
On 19 Oct 2006 21:36:04 -0700, Amber wrote:
>Hugo Kornelis,are you here?
As you see, I am now <g>.
The answer took a while because I also have a family and a job that
actually pays my bills. Giving free support comes only after that - and
if time is limited, I answer questions in various locations in a
round-robin fashion.
--
Hugo Kornelis, SQL Server MVP
Navigation:
[Reply to this message]
|