shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Cservenák <>
Subject Re: Question regarding WildcardPermission
Date Fri, 12 Nov 2010 12:49:30 GMT
Hi Les,

without implying or answering to your concerns below (I do agree with your
concerns), and just for fun, last night I played a bit, and created "spatial
permissions" for Shiro :D

You can "grant" permissions based on points in space :D :D  ("space" as the
most generic definition). Examples with 2d and 3d space, and a special space
defined on trees (n-trees) that actually implements Philippe's case and much
more. And some examples with finite spaces too.

It was really fun, but am not sure at all, would it have any practical
usage. For best "description" (last night was unable to type javadoc, one
hand was occupied with a beer keg), look at the UTs.

Also, there is a funny part, about spatiality-misuse, but allowing you to
define a complete sets of beneficiaries with only a few permissions.

Disclaimer: this as is, may not be used in flight control, but I did not
test it completely with shiro either, so if this proves unworkable, don't
blame me! It was a long time when I was playing with Shiro's internals.
Also, this is unfinished. To utilize this, you need more stuff, like some
SpatialPermissionProvider etc.

Have fun,

On Fri, Nov 12, 2010 at 1:26 AM, Les Hazlewood <>wrote:

> Now that I've thought about this a bit more, I'm curious - might you
> be tying the concept of access too closely to the UI representation?
> To me, there seems to be a high risk of tight coupling in this case.
> Let me explain.
> Let's use Tamás's previous example of app:taksLists/cstamas/T01:read
> We want to first check to see if the user is currently permitted to
> view the taskList with id 'cstamas'.  If so, this means the user
> should be able to show the 'task lists panel'.
> e.g. in existing Shiro capabilities:
> if ( subject.isPermitted("taskList:read:cstamas") ) {
>    //enable the panel
> }
> Then, we additionally want to check to see if the current user is able
> to see the task with ID 'T01'.  That translates (logically) to another
> check:
> if ( subject.isPermitted("task:read:T01") ) {
>    //show the task with id T01
> }
> Both of these checks reflect what you're actually trying to accomplish
> in the sense of raw functionality.  They are not forced to mirror how
> you might represent this in the UI.  For example - what if your UI
> changes or is modified to where the tree might not make as much sense?
>  Using my example, you don't have to change how the permissions are
> represented in your data store, because they're not tightly coupled to
> what the UI is trying to do.  This decoupled approach is likely to be
> much more resilient/robust.
> Also note that in the filesystem example, just because I have read
> access to /a/b/c/d.txt, it does not necessarily mean I have read
> access to the 'b' directory.  I may not be able to see anything in the
> 'b' directory - it just means that I can reference b in the context of
> getting to d.txt.  For example, you can try this in linux:
> (as root):
> # mkdir /tmp/a/b/c
> # touch /tmp/a/b/c/d.txt
> # chmod ugo+r /tmp/a/b/c/d.txt
> # chmod go-r /tmp/a/b
> (as a non-root user):
> > less /tmp/a/b/c/d.txt
> (you can read the file fine)
> > cd /tmp/a/b
> > ls
> (permission denied).
> Because I have 'execute' (+x) permission on the b directory, I can
> reference files below it for which I have prior knowledge.  But
> because I don't have read permission for the 'b' directory, I can't
> see anything in it.
> Anyway - it's an interesting point.  I'd just caution about coupling
> the permission structure and its use in security policies too closely
> with UI/client-level concerns if you can avoid it.  That would seem
> brittle to me.
> Les
> On Thu, Nov 11, 2010 at 3:55 PM, Les Hazlewood <>
> wrote:
> > Philippe and Tamás,
> >
> > I think your ideas are great actually and the idea makes quite a lot
> > of sense depending on the application's needs.
> >
> > I don't see why there couldn't be something like a TreePermission
> > implementation in Shiro that people could choose to use if they
> > wanted.  It would have to be designed very well to ensure it is
> > flexible, but it's a very interesting idea.
> >
> > If anyone wants to give this a shot, please open a Jira issue to keep
> > track of it and discuss it on the dev list.
> >
> > Great stuff!
> >
> > Les
> >
> > On Thu, Nov 11, 2010 at 1:21 PM, Philippe Laflamme <>
> wrote:
> >>
> >> I did succeed in implementing my own Permission class and making my
> use-case
> >> work, so thanks a lot for Shiro's flexibility. In that respect, it's
> really
> >> nicely done. I did have to copy/paste some WildcardPermission code which
> I
> >> would rather not. It may need some additional protected methods; I'll
> try to
> >> make a patch.
> >>
> >> I realize now that "bubbling-up" permissions is not appropriate in all
> >> situations. I'd like to get some input on how I can implement my
> use-case
> >> with Shiro.
> >>
> >> The main issue I have is that in order to access finer-grained
> permissions,
> >> I first need to test the coarser-grained ones. Using a file-system as an
> >> analogy (/a/b/c): to reach the 'c' folder, I have to read 'a', 'b'
> first.
> >> But I want to manage permissions at the "c" level, meaning I want to
> grant
> >> access to "c" which would then imply access to "a" and "b".
> >>
> >> I now realize that some permissions shouldn't bubble up. For example, if
> I
> >> grant write to 'c', I don't want that to mean write to 'b' and 'a' as
> well.
> >> That said, I would want it to mean read 'b' and 'a' since the user would
> >> need to "reach" 'c' in order to write to it.
> >>
> >> So in Shiro terms, I guess what I'm saying is:
> >>
> >> fs:read:a:b:c implies fs:read:a:b and fs:read:a
> >> fs:write:a:b:c implies fs:read:a:b and fs:read:a
> >> more generally
> >> fs:*:a:b:c implies fs:read:a:b and fs:read:a
> >>
> >> The system would allow read on "parent" entities when you have any
> >> permission on one of its child. It bubbles up, but "downgrades" the
> >> permission.
> >>
> >> Obviously, this is very different from WildcardPermissions and is very
> >> specific to my use-case...
> >>
> >> Any thoughts on this from anyone?
> >> --
> >> View this message in context:
> >> Sent from the Shiro User mailing list archive at
> >

View raw message