|
Prev: A simpler truncation function that renders credit card numbers unreadable
Next: Sleep command in db2
From: Troels Arvin on 23 Apr 2008 10:35 Hello, Quoting http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/ com.ibm.db2.luw.sql.ref.doc/doc/r0000935.html : Group privileges are not considered for any table or view specified in the CREATE VIEW statement. I discovered this today because a user complained that she couldn't create a simple view referring to a table to which she had all privileges. Why does DB2 care if the user or the group has the required SELECT privilege on the base table? (Managing access on a per-user basis is really a problem for us, we need to be able to do it by groups. Otherwise the DBA needs to be involved in too many tasks, instead of having the help desk handle it through central group membership administration.) -- Regards, Troels Arvin <troels(a)arvin.dk> http://troels.arvin.dk/
From: Serge Rielau on 23 Apr 2008 15:26
Troels Arvin wrote: > Hello, > > Quoting http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/ > com.ibm.db2.luw.sql.ref.doc/doc/r0000935.html : > > Group privileges are not considered for any table or > view specified in the CREATE VIEW statement. > > I discovered this today because a user complained that she couldn't > create a simple view referring to a table to which she had all privileges. > > Why does DB2 care if the user or the group has the required SELECT > privilege on the base table? > > (Managing access on a per-user basis is really a problem for us, we need > to be able to do it by groups. Otherwise the DBA needs to be involved in > too many tasks, instead of having the help desk handle it through central > group membership administration.) > The problem is that DB2 is not informed when the definer gets ejected from an OS GROUP. DB2 9.5 supports ROLES however. Role membership is managed within DB2 and therefore ROLE membership is considered. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab |