Tiago Espinha wrote:
Hello Kathey,
I overlooked this. I thought that roles were set and used on a by-user
basis; personally I find it a little counter-productive that the role
has to be chosen on every session. I am not totally sure how it goes
on SQL Server or MySQL for example, but at least Oracle loads up all
the privileges set to that user through roles. Then you can choose
during that session whether you want to enable or disable certain
roles: http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10004.htm
We might want to have a look into what's the most common behavior and
stick with that one; if on the other hand we are sticking to our way
on this and it differs from the other RDBMS' way then we might want
indeed to make this more explicit and obvious. I think it is easy to
overlook the fact that you have to SET a role on top of having been
granted that role.
Hi Tiago,
Thanks for testing this feature. At startup, a Derby session does not
have a default role. This is discussed in section 5.2 of the functional
specification attached to the master JIRA for roles, DERBY-2207. Having
a fresh set of eyes look at this feature is very helpful.
As the spec notes, according to the ANSI/ISO standard, the default role
for a session is vendor-specific. Derby is starting out neutral on this
topic.
Thanks,
-Rick
Tiago
On Thu, Apr 9, 2009 at 5:00 PM, Kathey Marsden
<[email protected] <mailto:[email protected]>> wrote:
Tiago Espinha wrote:
5) Tried to use TIAGO on another ij spawn and here is what I get:
ij> select * from adm.t1;
ERROR 42502: User 'TIAGO' does not have SELECT permission on
column 'F1' of table 'ADM'.'T1'.
I think before you do the select, you have to set the role, e.g
ij>set role readRole;
Should we make this clearer in the documentation?
http://db.apache.org/derby/docs/dev/devguide/cdevcsecureroles.html
Kathey
