When trying to configure SQL Server security at the column level I ran into
a problem: if I assigned column-level security through Enterprise Manager it
seemed to work fine, but after reopening the permission dialog box the
permissions on some columns disappeared.
After doing some research I can now simulate the behaviour when running the
following script. In Enterprise manager the security on column 'Col3' does
not show after running the script, though it is there.
CREATE TABLE test
(
Col1 int NOT NULL,
Col2 nvarchar(50) NOT NULL,
Col3 int NOT NULL
)
GO
ALTER TABLE test
DROP COLUMN Col2
GO
GRANT SELECT ON test(Col3) TO public
GO
/* Correct: returns select permission on Col3 */
sp_helprotect 'test'
GO
/* Bug! Does not return anything. */
/* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead of
max(colid) to determine maximum column number */
sp_MSobjectprivs N'test','column',null,null,null,null,0,1
GO
Enterprise Manager seems to use the sp_MSobjectprivs procedure to retrieve
the column permissions, but that one fails if columns are not numbered
consecutively (as caused by the DROP COLUMN).
Stefan Cuypers.
Dear Stefan,
Thank you for your feedback. I have reproduced the problem. Please rest
assured that we do understand your concerns and that the known issue is
being worked in development with priority after we report it via our
internal channel. We strive to capture any and all product issues / product
feedback so as to ensure that we are continuously developing Microsoft
products to meet customer needs. This is exactly why feedback such as
yours is always taken very seriously.
While we also hope to see the issue fixed as soon as possible, we have
re-confirmed with the development team that there are no better workarounds
at this time. If there are any updates on the issue, I will do my best to
be the first one to let you know.
Once again, thank you for your time and feedback.
Sincerely,
Bill Cheng
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
| From: "Stefan Cuypers" <stefan.cuypers@.nospam.nospam>
| Subject: Problem with viewing column permissions in Enterprise Manager
| Date: Fri, 2 Jul 2004 16:15:01 +0200
| Lines: 35
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.3790.0
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.132
| Message-ID: <#kQW57DYEHA.2908@.TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.tools
| NNTP-Posting-Host: d576ae10.kabel.telenet.be 213.118.174.16
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.tools:24406
| X-Tomcat-NG: microsoft.public.sqlserver.tools
|
| When trying to configure SQL Server security at the column level I ran
into
| a problem: if I assigned column-level security through Enterprise Manager
it
| seemed to work fine, but after reopening the permission dialog box the
| permissions on some columns disappeared.
| After doing some research I can now simulate the behaviour when running
the
| following script. In Enterprise manager the security on column 'Col3' does
| not show after running the script, though it is there.
| CREATE TABLE test
| (
| Col1 int NOT NULL,
| Col2 nvarchar(50) NOT NULL,
| Col3 int NOT NULL
| )
| GO
| ALTER TABLE test
| DROP COLUMN Col2
| GO
| GRANT SELECT ON test(Col3) TO public
| GO
| /* Correct: returns select permission on Col3 */
| sp_helprotect 'test'
| GO
| /* Bug! Does not return anything. */
| /* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead of
| max(colid) to determine maximum column number */
| sp_MSobjectprivs N'test','column',null,null,null,null,0,1
| GO
|
| Enterprise Manager seems to use the sp_MSobjectprivs procedure to retrieve
| the column permissions, but that one fails if columns are not numbered
| consecutively (as caused by the DROP COLUMN).
|
| Stefan Cuypers.
|
|
|
|||Bill,
Thanks for the feedback. I'm glad you take it seriously and will try to fix
it in a next update.
Stefan.
""Bill Cheng"" <billchng@.online.microsoft.com> wrote in message
news:jNqMXDOYEHA.2352@.cpmsftngxa06.phx.gbl...
> Dear Stefan,
> Thank you for your feedback. I have reproduced the problem. Please rest
> assured that we do understand your concerns and that the known issue is
> being worked in development with priority after we report it via our
> internal channel. We strive to capture any and all product issues /
product
> feedback so as to ensure that we are continuously developing Microsoft
> products to meet customer needs. This is exactly why feedback such as
> yours is always taken very seriously.
> While we also hope to see the issue fixed as soon as possible, we have
> re-confirmed with the development team that there are no better
workarounds
> at this time. If there are any updates on the issue, I will do my best to
> be the first one to let you know.
> Once again, thank you for your time and feedback.
> Sincerely,
> Bill Cheng
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> --
> | From: "Stefan Cuypers" <stefan.cuypers@.nospam.nospam>
> | Subject: Problem with viewing column permissions in Enterprise Manager
> | Date: Fri, 2 Jul 2004 16:15:01 +0200
> | Lines: 35
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.3790.0
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.132
> | Message-ID: <#kQW57DYEHA.2908@.TK2MSFTNGP10.phx.gbl>
> | Newsgroups: microsoft.public.sqlserver.tools
> | NNTP-Posting-Host: d576ae10.kabel.telenet.be 213.118.174.16
> | Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
> | Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.tools:24406
> | X-Tomcat-NG: microsoft.public.sqlserver.tools
> |
> | When trying to configure SQL Server security at the column level I ran
> into
> | a problem: if I assigned column-level security through Enterprise
Manager
> it
> | seemed to work fine, but after reopening the permission dialog box the
> | permissions on some columns disappeared.
> | After doing some research I can now simulate the behaviour when running
> the
> | following script. In Enterprise manager the security on column 'Col3'
does
> | not show after running the script, though it is there.
> | CREATE TABLE test
> | (
> | Col1 int NOT NULL,
> | Col2 nvarchar(50) NOT NULL,
> | Col3 int NOT NULL
> | )
> | GO
> | ALTER TABLE test
> | DROP COLUMN Col2
> | GO
> | GRANT SELECT ON test(Col3) TO public
> | GO
> | /* Correct: returns select permission on Col3 */
> | sp_helprotect 'test'
> | GO
> | /* Bug! Does not return anything. */
> | /* Problem is that sp_MSobjectprivs uses count(*) on syscolumns instead
of
> | max(colid) to determine maximum column number */
> | sp_MSobjectprivs N'test','column',null,null,null,null,0,1
> | GO
> |
> | Enterprise Manager seems to use the sp_MSobjectprivs procedure to
retrieve
> | the column permissions, but that one fails if columns are not numbered
> | consecutively (as caused by the DROP COLUMN).
> |
> | Stefan Cuypers.
> |
> |
> |
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment