Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Стоит задача: Написать SQL-процедуры для автоматизированного заведения нового пользователя и задания ему прав доступа к соответствующим таблицам и процедурам. Зачем это нужно: дать менеджерам верхнего уровня возможность управления своими подчинёнными в отсутствие сисадмина. Среди этих менеджеров потенциально могут быть мошенники, поэтому логин "sa" давать им нельзя, все процедуры должны работать под их собственным логином. Западло #1: хранимые процедуры sp_addlogin , sp_adduser , sp_droplogin и sp_dropuser работают только в том случае, если ты зашёл под логином администратора. SQL сервер не позволяет модифицировать хранимые процедуры, находящиеся в базе данных "Master" даже администратору. Западло #2: инструкции " GRANT * ON * TO user " и " REVOKE * ON * FROM user " не позволяют использовать в поле " user " переменную, только явно прописанное имя пользователя, поэтому их не удаётся поместить в процедуру так, чтобы ей передавалось имя пользователя, которому контролируемым образом назначаются права доступа. Выхода из этой ситуации я найти не смог ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2001, 16:09 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Менеджеры смогут выполнять подобные функции, если их логины включить в фиксированную роль сервера Security Administrators. Лично я не рекомендую вообще так поступать - это существенное ослабление системы безопасности. Создавать и удалять пользователей и роли должен именно администратор, если только у вас не такая текучка, как в мавзолее в советские времена. А вот управление правами на объекты доступно любому юзеру, которому предоставлены права с опцией WITH GRANT OPTION. При изъятии прав необходимо использовать опцию CASCADE - тогда изымаются права также у тех, кто получмл их от пользователя, у которого изымаются соответствующие права. Это более муторный, но гораздо более безопасный подход. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2001, 16:49 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Пользователей конечно должно заводить админы. А вот права на конкретные действие лучше проверять в хранимых процедурах, т.е. для этого надо организовать системы права, к примеру завести табличку что типа tUsers, в ней поля: логин пользователя, ну и поля которые определяют права, а в хранимой процедуре это дело проверять т.е. вызвал пользользователь процедуру, она там всоответсвии с логин провереят может это делать пользователь или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 08:15 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
А если давать права пользователям не напрямую на таблицы, а на выполнение хранимых процедур, которые реализуют правильную логику выполнения операций над данными. Т.е. пользователеь таблиц вообще не видит: хочешь скажем добавить запись - используй соответсвующую процедуру, если имеешь опять же права на ее выполнение >к примеру завести табличку что типа tUsers, в ней поля: логин пользователя, ну и поля >которые определяют права, а в хранимой процедуре это дело проверять т.е. вызвал >пользользователь процедуру, она там всоответсвии с логин провереят может это делать >пользователь или нет. Это по-моему уже реализовано в самом SQL и имеется соответсвующая функция PERMISSIONS ([ objectid [ , 'column' ] ] ). Тем как будет поддерживаться актуальность такой таблицы ? Конечно, если в вашей системе нужно иметь расширенный набор прав (например, кто-то может править проведенные накладные, а кто-то только просматривать), то ваше предложение может быть реализовано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 08:50 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Ты меня обсолютно не понял!!!! Я имел ввиду СИСТЕМУ ПРАВ!!! что это такое(но всё зависит от конкретно случаю), к примеру: есть некая система учета клиентов, и в ней следующая система: 1. менеджеры, они могут создавать, редактировать клиентов и смотреть только своих клиентов. 2. начальник, могут создавать клиентов, редактировать клиентов менеджеров (или не могут), и смотреть своих клиентов и клиентов менеджеров. 3. аналитик, он может только смотреть клиентов причём всех таки образом в таблице tUsers, два поля логин и роль (соответсвенно 1-менеджер, 2-начальник, 3-аналитик), соотвественно в своих процедурох и вьюхах ты это легко проверяешь, т.е. что может делать конкретный пользователь. Но самый примитивнийший пример, в принцыпе в так духе у нас так всё сделано, но права описываются даже в нескольких таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 09:15 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Всё бы ничего, господа, кабы не было одно "но", как говорится. To Tarantino . Думал я уже о механизме регистрации прав в таблице и проверке их в функциях, но он не применим в нашем случае, потому что защищать данные надо не только от изменения, но и от доступа, чтобы, например, какой-нибудь приёмщик брака, например, не мог узнать оборот компании, грубо говоря. Это можно было бы сделать, если бы можно было извлекать данные из базы при помощи хранимых процедур, но драйверы ODBC сделать этого не позволяют To Glory . А что это за функция "PERMISSIONS"? У нас MS SQL 7.0, он говорит, что такой функции (процедуры) у него нету. Это примочка SQL 2000? Каков её полный синтаксис? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 10:06 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Я так понимаю, что эта функция из SQL2000 "PERMISSIONS Returns a value containing a bitmap that indicates the statement, object, or column permissions for the current user. Syntax PERMISSIONS ( [ objectid [ , 'column' ] ] ) Arguments objectid Is the ID of an object. If objectid is not specified, the bitmap value contains statement permissions for the current user; otherwise, the bitmap contains object permissions on the object ID for the current user. The object specified must be in the current database. Use the OBJECT_ID function with an object name to determine the objectid value. 'column' Is the optional name of a column for which permission information is being returned. The column must be a valid column name in the table specified by objectid. Return Types int Remarks PERMISSIONS can be used to determine whether the current user has the necessary permissions to execute a statement or to GRANT a permission on an object to another user. The permissions information returned is a 32-bit bitmap. The lower 16 bits reflect permissions granted to the security account for the current user, as well as permissions applied to Microsoft® Windows NT® groups or Microsoft SQL Server™ roles of which the current user is a member. For example, a returned value of 66 (hex value 0x42), when no objectid is specified, indicates the current user has permissions to execute the CREATE TABLE (decimal value 2) and BACKUP DATABASE (decimal value 64) statement permissions. The upper 16 bits reflect the permissions that the current user can GRANT to other users. The upper 16 bits are interpreted exactly as those for the lower 16 bits described in the following tables, except they are shifted to the left by 16 bits (multiplied by 65536). For example, 0x8 (decimal value is the bit indicating INSERT permissions when an objectid is specified. Whereas 0x80000 (decimal value 52428 indicates the ability to GRANT INSERT permissions because 524288 = 8 x 65536. Due to membership in roles, it is possible to not have a permission to execute a statement, but still be able to grant that permission to someone else. The table shows the bits used for statement permissions (objectid is not specified). Bit (dec) Bit (hex) Statement permission 1 0x1 CREATE DATABASE (master database only) 2 0x2 CREATE TABLE 4 0x4 CREATE PROCEDURE 8 0x8 CREATE VIEW 16 0x10 CREATE RULE 32 0x20 CREATE DEFAULT 64 0x40 BACKUP DATABASE 128 0x80 BACKUP LOG 256 0x100 Reserved The table shows the bits used for object permissions that are returned when only objectid is specified. Bit (dec) Bit (hex) Statement permission 1 0x1 SELECT ALL 2 0x2 UPDATE ALL 4 0x4 REFERENCES ALL 8 0x8 INSERT 16 0x10 DELETE 32 0x20 EXECUTE (procedures only) 4096 0x1000 SELECT ANY (at least one column) 8192 0x2000 UPDATE ANY 16384 0x4000 REFERENCES ANY The table shows the bits used for column-level object permissions that are returned when both objectid and column are specified. Bit (dec) Bit (hex) Statement permission 1 0x1 SELECT 2 0x2 UPDATE 4 0x4 REFERENCES A NULL is returned if a specified parameter is NULL or invalid (for example, an objectid or column that does not exist). The bit values for permissions that do not apply (for example EXECUTE permissions, bit 0x20, for a table) are undefined. Use the bitwise AND (&) operator to determine each bit set in the bitmap returned by the PERMISSIONS function. The sp_helprotect system stored procedure can also be used to return a list of object permissions for a user in the current database. " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 10:26 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
Вот именно что мой способ тебе поможет что бы приёмщик брака этого не увидел, т.е. даёшь всем юзерам права public, все таблицы закрыаешь от группы public (insert, update, delete, select), делаюши вьюхи и процедуры которые соответсвенно открыты на select и exec для public и внутри них проверяшь может ли приёмщик брака получать эти данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 11:09 |
|
||
|
Как обойти 2 (два!) западла, подкинутых создателями MS SQL?
|
|||
|---|---|---|---|
|
#18+
2Serge Интересно почему это драйверы ODBC не позволяют извлекать данные из хранимых процедур. Сделал в конце процедуры select @par1, @par2 ... перехватил в программе в RecordSet и вперед ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2001, 14:56 |
|
||
|
|

start [/forum/topic.php?fid=46&fpage=3553&tid=1825850]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 369ms |

| 0 / 0 |
