Суть проблемы. ASA 9.0.2.3581
Есть хранимая процедура, скажем dba.OuterProc. Процедура возвращает result set.
Это процедура внутри использует выборку из другой процедуры, скажем ns.InnerProc.

Есть пользователь user1. У него есть права на выполнение dba.OuterProc, но нет прав на ns.InnerProc.

Так вот, если user1 вызывает процедуру через
то все отрабатывается корректно - он молча получает требуемую выборку.

Но если вызвать
то ASA ругается, что нет прав на выполнение ns.InnerProc.

Что за бред? Это так и должно быть? Навскидку в доке не нашёл упоминания о подобных различиях в трактовке прав.

SiemarglАлександр Гoлдун,

Во люди пошли. 1 раз сервер обманули и интересутся, почему 2й раз не выходит )))))
Да потому что он дурак. Был бы умным, и 1й раз бы дулю скрутил.

Переписывайте правильно. Такие "логические бомбы" могут потом вылезти и при смене версии или даже патча.
Уважаемый! Вы бредите. Либо не поняли смысл моего поста.
Моё использование процедур и защиты абсолютно корректное. Это нормальная практика - ограничить права на выполнение каких-либо действий таким способом, чтобы пользователь мог их сделать только при помощи процедуры.

И в ASA это задекларировано в документации - процедуры выполняются с правами владельца
Для пользователя процедура - черный ящик в плане прав. Тоже самое относится к VIEW, но с оговорками: если есть права непосредственно на VIEW, то права на упоминаемые внутри таблицы необязательны. Если же прав на VIEW нет, то проверяются права как при обычном запросе.

Следуя вашей логике, не было бы возможности, скажем, запретить непосредственное удаление из таблицы, но разрешить это делать из процедуры.

Описанный мною баг - это однозначно баг до тех пор, пока не доказано иное, а именно не указано, где в документации описано подобное поведение.

escapistА разве не должны проверятся права на InnerProc от хозяина OuterProc?

Именно так и должно быть! И так оно происходит, если не селектить из процедур. А вот при выборке из процедур этот механизм не срабатывает, что явно является ошибкой ASA.

Вроде раньше именно так было(если внутри идёт выборка из таблицы,то давали право select хозяину процедуры,а не пользователю от которого была вызвана процедура)
escapist
А теперь у меня схожий вопрос только уже по представлениям:
есть представление dba.innerview(выборка из таблицы dba.table1);

есть представление u.outerview,которое выбирает из представления dba.innerview(но права такого пользователю u не было дано,равно как и на таблицу dba.table1);

есть пользователь user1 у которого есть право на u.outerview,но нет на dba.innerview(и нет на таблицу dba.table1)
Пользователь user1 легко делает select*from u.outerview,да и не важно что будет написано в этом представлении(можно из dba.table1)-все запросы проходят на ура,лишь бы было право на select из этого представления.Это так и должно быть?


Да, именно так и должно быть.

SiemarglВообще идеология защиты - если запрещено одно из вложенных действий - невозможно все.
...
2 Iller - обычно наследуются запрещения, а не разрешения.
Вы документацию по ASA читали? Мы обсуждаем тут не "вообще идеологию" и не "обычно наследуются" , а вполне четко задокументированную идеологию, которая на моей памяти благополучно и успешно работала и использовалась со времен SQL Anywhere 5.0, ибо весьма логична и удобна.

И мне нужно именно такое использование защиты, и я рассчитывал, что это будет работать корректно, как всегда и как описано в доке.

iLLer
Можно вставить dummy-операции в тело процедуры, чтобы отвадить оптимизатор делать такую подмену.

Спасибо за идею. Помогло. Только сделал не dummy-операцию, а использовал временную таблицу во внешней процедуре: в нее загонялся результат внутренней и уже из нее селектилось.
Лишнее доказательство того, что это действительно баг.

SiemarglАлександр Гoлдун
Уважаемый! Вы бредите. Либо не поняли смысл моего поста.

Угу. Брежу. Поскольку не понял из первого поста сразу, что Вы тоже хотите получить два отказа в доступе)
Нет, я хотел корректный вызов внешней процедуры в любых вариантах одинаково БЕЗ отказов в доступе. Именно так, как оно и должно быть.

Если вы не знакомы с ASA, то вот ссылки для ознакомления, непосредственно по обсуждаемой теме:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.11.0.1/dbadmin_en11/uvproc.html
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.11.0.1/dbadmin_en11/perexp.html