On 09-02-2021 17:48, Alex Peshkoff via Firebird-devel wrote:
I do wonder about this case. Specifically, why am I not able to
execute SET ROLE TESTROLE in this case? According to the mapping I'm
allowed to use this role.
According to SQL specification set role shall fail if user is not
granted the role. And allowed to use due to mapping and granted are
different things. That's the second reason to have such form of
statement at all, first - to help not think about what particular role
became available due to mapping. In such scenario:
set role special_role;
-- perform some action that require special_role
-- need to restore originak trusted role
set trusted role;
The problem I see is that it requires knowledge how the original role
was obtained. This isn't really problematic for interactive users, but
might be more of an issue for programs that for example want to restore
the original role after temporarily switching roles and generate a
statement using, for example,
SELECT 'set role "' || TRIM(CURRENT_ROLE) || '";' FROM RDB$DATABASE
then changes the role, and then tries to revert to the original role
using the generated statement. Then again, such scenario is probably not
very common.
Maybe that is something we need to consider if this actually happens
though, but we could bend the interpretation of the standard requirement
so that a role assigned through a mapping rule is also considered
granted to the user.
If I have to summarize this feature, it is "allows the user to assume
the mapped role, even when they connected with a different role".
Would that be accurate?
May be more accurate 'set current_role = trusted(mapped) role', no
matter why curent_role differs.
Would SET MAPPED ROLE have been a better name for this feature?
Trusted here means that it comes from plugin to which database trusts
enough (via mappings) to make that role available even if it was not
explicitly granted.
As I understand it, trusted roles are a subset of mapped roles (e.g. a
mapped role is any role assigned by a MAPPING rule, while a trusted
role is a mapped role which has not been explicitly granted to the user).
Never thought this way :-)
Thanks, I think I now have sufficient understanding of SET TRUSTED ROLE
to write the documentation.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
