Как сменить пользователя из хранимой процедуры?

← →
MS SQL (2006-06-09 19:58) [0]

Необходимо сменить пользователя из хранимой процедуры.
Т.е., пользователь входит как Гость, а затем вызывает хранимую процедуру, передавая дополнительный логин и пароль. Процедура должна проверить, есть ли такой пользователь в БД, проверить пароль, и, если все прошло удачно - сменить пользователя на другого, с более расширенными правами. То есть, в самой хранимой процедуре можно прописать и логин, и пароль для этого другого (с расширенными правами) пользователя. SETUSER, EXECUTE AS - не требуют пароля, и выполняются только из-под админа. Есть ли какое-то решение?

← →
Desdechado © (2006-06-09 20:56) [1]

нафига козе баян?
Сделай, чтоб процедура при успешной проверке что-то возвращала, после чего клиент переподключался с нормальной учетной записью.

← →
Johnmen © (2006-06-09 21:26) [2]

Такого, хм, идиотического :) решения просто не может быть. Ибо не имеет ничего общего с общей концепцией безопасности и разграничения прав...

← →
DrPass © (2006-06-10 11:36) [3]

Если добавить среднее звено, можно в нем и так извратиться. Не средствами MS SQL, конечно. Но можно

← →
MS SQL (2006-06-10 13:42) [4]

Ну а как же, дух подмастерьев Delphi все еще жив.

нафига козе баян?

Для кого и серна - корова. Я это... не спрашивал твоего великого и единственного мнения о поводу такого решения.

Я спрашивал, какими способами можно решить такую задачу.

Тебе нечего сказать? Хочешь, помогу советом?

Такого, хм, идиотического :) решения просто не может быть. Ибо не имеет ничего общего с общей концепцией безопасности и разграничения прав...

Надстройка над любой системой - не идиотическое решение, а только лишь надстройка. Какие нарушения "общей концепции безопасности" ты тут увидел? То, что аутентификация ведется не средствами SQL Server? Так это кто сказал, что только эти средства хороши? Ты? Ну тогда зачем Windows Authentication mode? Или мне кто-то может запретить сделать свою систему аутентификации? А понятие "роль" - это ли не объединение нескольких пользователей под одним набором прав? Кто запрещает пускать несколько пользователей под одной учетной записью? Тем более, что аутентификация при данном решении должна производиться внутри хранимой процедуры. Тем более, что каждый пользователь все равно продолжает пользоваться своим отдельным логином и паролем. То есть, мне это решение нужно для усиления безопасности.

P.S. Еще раз: меня не интересуют ваши мнения о таком решении. Тем более, что вы все равно всех тонкостей не знаете. Меня интересует решение. Кто-то может сказать что-то конструктивное?

P.P.S. Потрепаться - несколькими конференциями дальше.

← →
MS SQL (2006-06-10 14:20) [5]

Пояснения для любителей клубнички:

Есть БД на MS SQL Server. С этой БД работает большое количество пользователей. Они создают, читают, модифицируют данные в таблицах. Данных - много.

Есть программа, работающая с этой БД. Необходимо обеспечить возможность доступа к БД только из этой программы.

Если каждого пользователя прописывать на сервере, давая логин, пароль и набор прав, то эти пользователи могут подключится к БД помимо программы. А как следствие - скачать из БД всю информацию. То есть, на данный момент, для "продвинутого" пользователя это не является проблемой.

Решение следующего плана: Запретить доступ к БД всем, кроме администраторов и единственного пользователя, создаваемого на этапе создания БД. Пароль этого пользователя не знает никто, так как он генерируется на этапе создания БД и прописывается только в хранимую процедуру, которая тут же создается в БД. Кроме того, в самой БД есть вторичная таблица пользователей программы с логинами и паролями (MD5). Клиентское приложение запрашивает у пользователя его логин и пароль. Затем - хэширует пароль в MD5, производит с ним дополнительные трансформации, и передает логин и пароль в хранимую процедуру. Процедура детрансформирует хэш, по внутренней таблице проверяет логин и пароль, и если все ОК - должна сменить учетную запись текущего пользователя (он вначале входит как гость только лишь с правом выполнения только этой процедуры) на учетную запись внутреннего пользователя. Таким образом, программа может работать с БД, а пользователь не знает логина и пароля для произвольного доступа к БД. То есть, к БД при помощи сторонних средств уже не подключится.

P.S. Если кому не нравится трактовка "все входят под одной учетной записью", то пусть думает, что "всем пользователям назначена одна и та же роль". Хотя, если еще более углубляться, то таких "встроенных" пользователей несколько, и, в зависимости от логина и пароля программы, в хранимой процедуре должны подключаться разные пользователи (ну, если кому неймется - роли) БД.

P.P.S. Теперь, когда я все тут расписал "маслом на холсте", кто-то скажет, как сменить текущую учетную запись внутри хранимой процедуры?

← →
MS SQL (2006-06-10 16:09) [6]

Вот еще:

В программе есть некая группа пользователей, которые могут создавать новых пользователей. Для выполнения таких задач этой группе надо назначить соответствующие права на сервере. Таким образом, простая возможность создавать пользователей программы оборачивается также в возможность выполнять некоторые администраторские задачи на сервере.

То есть, администратор ушел в отпуск, дал одному из опытных пользователей право создавать пользователей программы, а это обернулось тем, что этот пользователь имеет админские права на сервере. Использвание же "закрытых" учетных записей, вход под которыми может быть осуществлен только через хранимую процедуру, не дает напряму этому опытному пользователю прав на сервере. То есть, он эти админские права может поиметь только используя программу. А пароля и логина для входа на сервер мимо программы - не имеет.

P.S. Вопрос остается в силе.

← →
Вася (2006-06-10 19:59) [7]

сладкий мой!

известно, что чем сложнее механизм, тем легче ломается
а также известно, что любая цепь не прочнее своего самого слабого звена

все твои потуги подпадают под это определение

← →
Sergey Masloff (2006-06-10 20:55) [8]

Я не большой знаток MS SQL
Если я правильно понял о чем идет речь то в Oracle это называется
Secure Application Roles
Если в MS SQL есть аналог процедур с правами вызывающего то можно скорее всего. Если это так важно то может почитать документацию оракла оценить есть ли соотв. механизмы в MS SQL и попробовать. Читать Concepts глава 20 и от нее по ссылкам. Название топика я привел.

вот краткая цитата:
Oracle provides secure application roles, which are roles that can only be enabled by authorized PL/SQL packages. This mechanism restricts the enabling of such roles to the invoking application. Security is strengthened when passwords are not embedded in application source code or stored in a table. Instead, a secure application role can be created, specifying which PL/SQL package is authorized to enable the role. Package identity is used to determine whether privileges are sufficient to enable the roles. Before enabling the role, the application can perform authentication and customized authorization, such as checking whether the user has connected through a proxy. Because of the restriction that users cannot change security domain inside definer"s right procedures, secure application roles can only be enabled inside invoker"s right procedures.

← →
DrPass © (2006-06-10 22:25) [9]

> P.S. Вопрос остается в силе

Ответ - тоже в силе. В MS SQL - никак. Кроме того, если ты собрался городить такую систему, зачем вообще подменять логины? Заведи один-единственный технологический бюджет с нужными правами, пропиши его в приложение в зашифрованном виде, а пользователей авторизуй по каким-нибудь своим суррогатным бюджетам из
"вторичной таблицы пользователей программы с логинами и паролями (MD5)" (с)

← →
Sergey Masloff (2006-06-10 22:44) [10]

Да я еще раз перечитал вопрос. То что я написал - это естественно не изменение юзера а изменение его (того же самого пользователя) контекста безопасности. То есть расширяем права определенному пользователю при его особом подключении.

← →
Shaman_Naydak (2006-06-12 00:02) [11]

Классический вариант решения вопроса, как указал DrPass - это переход на трехзвенку.
Ежели делать на клиент-сервере, то предлагаю следующее:
Во-первых, ни в коем случае не пользоваться советом того же DrPass"a :) и не использовать "технологический бюджет с нужными правами в зашифрованном виде".. ибо это примитивизм, недостойный даже обсуждения.
Сила системы прав не должна заключаться в "непрозрачности и неизвестности" алгоритма.
Что касается клиент-серверной архитектуры, то во-первых, я не вижу проблемы в том, что клиент зайдя не из программы, видит данные, доступные ему. Главное, чтобы он не видел лишнего. Педлагаю все таки воспользоваться уже давно отточенным механизмом прав самой СУБД. То есть создать роли в БД, каждая из которыъ отвечает за некий атомарный набор прав над таблицами и пользователю добавить ряд ролей, которые ему нужны. (не забыть только убрать права с роли public.. хехе). Вот, что нужно сделать - так это процедуру добавляющую и убирающую в зависимости от требуемой "бизнес-роли" соответствующие "роли БД".
Теперь перейдем вопросу к тому как сделать так, чтобы вызов эту процедуру мог бы вызвать человек, который не имеет с точки зрения сервера прав грантовать. В 2005м SQLе вроде бы появилась возможность, чтобы выполнение процедуры было от имени "создателя", а не "вызывающего"..
Для 2000ного можно применить следующий ход конем. Вышеупомянутая процедура доступна для вызова только security adminy.. Но создается еще одна процедура, доступная соотв. "бизнес-админу", которая через OPENROWSET и зашитой в теле имени/паролю security admin"a вызывает 1ю процедуру.

Но я бы все равно за трехзвенку :)
Удачи в делах тяжких.

← →
MOA © (2006-06-13 10:51) [12]

>В 2005м SQLе вроде бы появилась возможность, чтобы выполнение процедуры было от имени "создателя", а не "вызывающего"..
Это было по жизни, в MSSQL 6.0 - точно. То же касается вьюх.

> [5] MS SQL (10.06.06 14:20)

Используемое для этих целей решение
запретить пользователю группы publik доступ куда либо кроме исполнения хранимых процедур
В БД хранятся данные о том к каким типам документов в каком состоянии какие права у тго или иного пользователя.
В начале каждой процедуры проверка - есть ли права на данное действие.
И пусто пользователь обселектится:)

Настрой анонимного вопрошающего попросту отталкивает. Имхо.

Как бы это сказать повежливее . . .
Городить огород двух РАЗНЫХ подходов к аутентификации - полный бред.
2 пути :
1) сразу даешь нормальные гранты (у MS SQL они довольно развиты)
2) всю логику и доступ к данным загоняешь в хранимки (если я ничего не путаю, они исполняются с правами DBO).
А вот наглости вам не занимать, молодой человек.

>они исполняются с правами DBO
С правами создателя процедуры или вьюхи.

Не проще ли создать в базе табличку с пользователями, паролями и правами
и сразу логиниться под под определённым юзером. Зачем делать лишние звенья с гостем и ХП? Ведь все равно в конечном итоге все сводится к передаче логина и пароля, сверке со списком допустимых юзеров и разрешение/запрет на вход.

А повысить свои привелегии в системе можно с помощью локального эксплойта ;-)))) Можешь организовать его в виде UDF, которая будет вызываться из твоей хитросделанной ХП :-))))

Как сменить пользователя из хранимой процедуры? Найти похожие ветки