[prev in list] [next in list] [prev in thread] [next in thread]
List: mondrian
Subject: RE: [Mondrian] Implicit access right for calculated member formulas
From: "Julian Hyde" <jhyde () pentaho ! com>
Date: 2010-08-12 22:04:18
Message-ID: 24B53465E58645AE872F5E7522469593 () mackerel
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I agree that it might be useful if a calc member could see more than the
current role. It could then act as a 'gatekeeper', and be used for
fine-grained access control. (In most relational database, views work this
way.)
However, that's not the way it is currently intended to work. Making it work
differently would take a bit of effort.
And, in some cases people would want to keep the current behavior. Most, in
fact, because the new behavior would blow a hole in access control and make
the system vulnerable if calc members were implemented carelessly. So we
would need a member property to control whether the calc member runs in the
access control context of the current user or of the cube owner (i.e.
system).
If anyone would like this behavior, they should log a feature request.
Julian
_____
From: mondrian-bounces@pentaho.org [mailto:mondrian-bounces@pentaho.org] On
Behalf Of Luc Boudreau
Sent: Thursday, August 12, 2010 11:58 AM
To: Mondrian developer mailing list
Subject: [Mondrian] Implicit access right for calculated member formulas
Hello everyone,
I'm working on a case about roles and access rights. I have the following
scenario.
A CalculatedMeasure in the schema has a formula which is based on the
members of a given level in a given hierarchy. There is one role defined.
The role is only allowed to view the All Member level, not it's children.
The role can also access the calculated member. So let's say:
* Cube
* Dimension
* Hierarchy
* All Member level
* Foo level
* Calculated Member
(references "Foo level")
* Role
* Cube grant
* Heriarchy grant on "All Member Level" only
When a query is executed with the defined role privileges, the calculated
member returns no data, because Mondrian uses the role's access rights to
resolve the members of the Foo level.
Is this the correct behavior, or should calculated members that are part of
the core schema (not the query inline ones) give the role an implicit access
right? I'm puzzled as to decide if this is a bug or not. It has some obvious
security implications. IMO, things are fine as they are, but I thought I'd
seek a second opinion.
Cheers!
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18943"></HEAD>
<BODY>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans">I agree that it might be useful if a calc member could see
more than the current role. It could then act as a 'gatekeeper', and be used for
fine-grained access control. (In most relational database, views work this
way.)</FONT></SPAN></DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans">However, that's not the way it is currently intended to work.
Making it work differently would take a bit of effort.</FONT></SPAN></DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans">And, in some cases people would want to keep the current
behavior. Most, in fact, because the new behavior would blow a hole in access
control and make the system vulnerable if calc members were implemented
carelessly. So we would need a member property to control whether the calc
member runs in the access control context of the current user or of the cube
owner (i.e. system).</FONT></SPAN></DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans">If anyone would like this behavior, they should log a feature
request.</FONT></SPAN></DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=643025721-12082010><FONT color=#000080 size=2
face="Lucida Sans">Julian</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> mondrian-bounces@pentaho.org
[mailto:mondrian-bounces@pentaho.org] <B>On Behalf Of </B>Luc
Boudreau<BR><B>Sent:</B> Thursday, August 12, 2010 11:58 AM<BR><B>To:</B>
Mondrian developer mailing list<BR><B>Subject:</B> [Mondrian] Implicit access
right for calculated member formulas<BR></FONT><BR></DIV>
<DIV></DIV>Hello everyone,<BR><BR>I'm working on a case about roles and access
rights. I have the following scenario. <BR><BR>A CalculatedMeasure in the
schema has a formula which is based on the members of a given level in a given
hierarchy. There is one role defined. The role is only allowed to view the All
Member level, not it's children. The role can also access the calculated
member. So let's say:<BR><BR>
<UL>
<LI>Cube
<UL>
<LI>Dimension
<UL>
<LI>Hierarchy
<UL>
<LI>All Member level
<UL>
<LI>Foo level</LI></UL></LI></UL></LI></UL>
<LI>Calculated Member<BR> <I>(references "Foo level")</I><BR>
<LI>Role
<UL>
<LI>Cube grant<BR>
<LI>Heriarchy grant on "All Member Level"
only</LI></UL></LI></UL></LI></UL>When a query is executed with the defined
role privileges, the calculated member returns no data, because Mondrian uses
the role's access rights to resolve the members of the Foo level. <BR><BR>Is
this the correct behavior, or should calculated members that are part of the
core schema (not the query inline ones) give the role an implicit access
right? I'm puzzled as to decide if this is a bug or not. It has some obvious
security implications. IMO, things are fine as they are, but I thought I'd
seek a second opinion.<BR><BR>Cheers!<BR></BLOCKQUOTE></BODY></HTML>
_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic