Люди подскажите что-то я торможу.
Вот кусок той статьи, вчера думаю дай проверю и получилось что действительно что ниже написано верно. Сегодня думаю, а как же этого избежать не пребегая к использованию
IS_MEMBER, думаю а может лучше проверить @@NESTLEVEL. И начинаю проверять, но что то теперь
вызов процедуры не выполняется из временной хранимой процедуры, может я вчера случайно не заметил того что у меня для того юзера было разрешение на EXEC, хотя вроде и смотрел его не было.

Перейдем к временным процедурам. К сожалению, Microsoft только к середине 2000 года заметила огромное упущение в работе с временными хранимыми процедурами - они позволяют любому пользователю выполнить любую (даже запрещенную для него) хранимую процедуру. Давайте рассмотрим эту ситуацию на примере из предыдущей главы. Запретим пользователю с именем manager выполнение процедуры dbo.TestProc:
DENY EXECUTE ON dbo.TestProc TO manager

Изменим текущего пользователя на manager.
SETUSER 'manager'
И выполним процедуру dbo.TestProc.
EXEC dbo.TestProc 'au_lname LIKE ''Gree%'' AND state IN (''CA'', ''MI'')'

В ответ мы получим:
Server: Msg 229, Level 14, State 5, Procedure TestProc, Line 1
EXECUTE permission denied on object 'TestProc ', database 'pubs', owner 'dbo'.


Теперь создадим временную процедуру #TestProc:


CREATE PROCEDURE #TestProc
(@where varchar(8000) = NULL)
AS
BEGIN
EXEC dbo.TestProc @where
END

И выполним ее:
EXEC #TestProc 'au_lname LIKE ''Gree%'' AND state IN (''CA'', ''MI'')'


Все прекрасно работает!

Как же обезопасить данные от таких ситуаций? Процедуре придется самой проверить, кто же ее запустил, и имеет ли он на это право. Допустим, у нас есть группа пользователей managers. Добавим в нее пользователя manager. Теперь с помощью функции IS_MEMBER() узнаем, принадлежит ли пользователь к этой группе. Добавим в начало процедуры dbo.TestProc строки:
IF (IS_MEMBER('managers') != 1)
BEGIN
RAISERROR('Только пользователи, входящие в группу ''managers'' могут вызывать эту процедуру', 16, 1) END

Так у меня не установлен на MSSQL 2000 сервис пак. Или эта проблема была на SQL 7.0 и в каком-то Sp эта проблема была устранена, а в 2000 ее и не было?