Бу-га-га.
Теперь без глума и детально.
Ну, если тебе настолько важно предоставлять персональный интерфейс юзеру, то можешь развлечься парсингом результатов sp_helprotect, почему бы и нет. Кстати, вывод у нее довольно однозначный и хорошо документированный:
- Код: Выделить всё
exec sp_helprotect 'MyTable', 'MyUser'
вернет все права пользователя MyUser (либо роли, смотря что это) на объект MyTable.
Впрочем, есть пара проблем:
1. Если права у тебя раздаются не персонально юзерам, а все-таки (я надеюсь) посредством включения юзеров в роли, то ты попал, потому как право, наследуемое через роль, не отображается в выводе sp_helprotect при запросе по имени пользователя. Следовательно, тебе на каждый чих придется сначала получать список всех ролей, явным или неявным членом которых является пользователь - включая членство ролей в других ролях! - и потом либо для каждой этой роли вызывать процедуру, либо вызывать ее один раз без указания имени роли и уже на клиенте разбирать полученный недетский рекордсет на предмет пересечения двух множеств. Можно написать эту процедуру целиком на T-SQL, но это тоже не будет решением проблемы, почему - смотрим дальше.
2. Если юзер включен в несколько ролей, одна из которых дает ему селект на таблицу, а другая запрещает ему это, то запрет имеет приоритет. Причем неважно, на каком уровне что дается. Это тебе тоже придется проверять ручками, и тут ты реально попадаешь, если решишь с этим связаться.
Учитывая все вышесказанное, смысл использования sp_helprotect становится крайне сомнительным. Более того, в сиквеле есть функция PERMISSIONS(), которая возвращает как раз сумму всех действующих прав - то, что тебе требуется. Правда, только для того пользователя, который ее запустил - но тебе ведь ничего другого и не нужно, как я понял. Впрочем, и с ней есть, опять-таки, пара проблем:
1. Она возвращает битовую маску в формате 32-битного целого, причем для каждого столбца будут дополнительные данные (права на SELECT / UPDATE из таблиц и представлений можно задавать с точностью до столбца). Не самое сложное в этой жизни, особенно по сравнению со следующим пунктом.
2. В BOL 2005 эта функция объявлена - lo and behold! - устаревшей. Рекомендуется больше не писать код с ее использованием, а все имеющиеся упоминания переделать на новую системную функцию fn_my_permissions. Это значит, что тебе придется писать разные версии кода под разные версии MS SQL Server. И если сейчас ты еще можешь все сделать на Permissions(), и это даже будет работать как на 2000, так и на 2005 сиквеле, то выход Katmai может стать для тебя маленькой белой лисичкой.
Помимо всего вышесказанного, в MSSQL 2005 появился такой тонкий момент, как Metadata Visibility Restrictions. Если вкратце, то клиент А может в общем случае не увидеть права клиента В. В твоем случае это не представляет особой проблемы, но в каких-нить мелочах, тем не менее, можешь налететь.
Ну как, ты все еще горишь желанием рисовать персональные формочки под набор прав в базе?..
