incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: Permission naming convention for using an application
Date Tue, 23 Mar 2010 08:10:33 GMT
You're right Marco, the comparison with the filesystem is falls short as in
a hierarchical filesystem there's a nesting the permission system can take
advantage of. In that graphs are like roots, even though they are named and
permissions can be assigned using wildcard expressions on the name of the

Clerezza is meant to be used with multiple graphs and the foremost reason to
split data into multiple graphs is that different parts of the data shall be
accessible by different groups of users. Uniongraph allow a user to see the
different graphs they have access to as one graph. The content graph as
returned by the content graph provider is such a union graph, this allows
for more data to be included when the user has more access rights. I was
thinking if it would be a good idea to change the set of graphs that
constitute the union content graph depending on the path(-prefix) of the

By default a clerezza instance is configured as follows:
- The system graph is accessible only by the admin user
- The content graph is world readable
- Users with the role CommunityUser have read-write rights to the graphs
matching the pattern "http://tpf.localhost/user/{username}/*"

@manuel: could you add the newly created graphs and roles?


On Mon, Mar 22, 2010 at 6:38 PM, Marco Zaugg <>wrote:

> Ok, taking your Graph-Level example with the comparison to the filesystem,
> you're basically talking about giving each user full read/write access to
> the root directory, although various users would just require read/write
> access to
> a subfolder?
> If that is what you're saying, shouldn't there not be multiple graphs
> similar to subdirectories on fileservers in order to control who has access
> to which part of the content structure?
> Or am I just too stupid to see the obvious?
> -----Original Message-----
> From: Reto Bachmann-Gmuer []
> Sent: Montag, 22. März 2010 18:27
> To:
> Subject: Re: Permission naming convention for using an application
> Rougly I'd say are 3 levels of permission restrictions.
> Graph-level: This is the most important level, it defines who can read and
> who can write to a triple collection. This can be compared to the access
> rights on a filesystem. It is not possible to grant or restrict permissions
> on subgraphs via this mechanism. The reason for this, is that such a
> feature
> would require operations of potentially non polynomial complexity on every
> access to the graph and is thus perfomance-wise a non-option.
> Service-Level: A service can do stuff for a user they potentially could not
> do directly on the graph. This is comparable to the sudo feature on a unix
> machine. Using a service a user might for example get a list of users from
> the system-graph without having read-write to the system graph. Services
> can
> be accessible via OSGi and/or via REST.
> App-Level:  On this level a user is prevented from using an application, of
> course the user could also be prevented from using the application by not
> having the respective Graph- or Service-level permissions, but in some
> situations one would simply like to prevent the user from being able to
> access features that might confuse them. In analogy in unix is the execute
> permission on a file.
> On Mon, Mar 22, 2010 at 6:00 PM, Marco Zaugg <
> >wrote:
> > Do I get that correct, although a user doesn't have a 'AppPermission'
> > to access, say the application front-end of the 'User Manager', he/she
> > could still access and
> > manipulate the graph through a script using the REST API?
> >
> > IMO this is not correct. A front-end application could consist of
> > different permissions, i.e. read/write access on a specific part of
> > the main content graph, or can access and open the application front-end.
> >
> > With this, a user could get read/write access on a graph without the
> > app front-end. Could also have both, App front-end access and graph
> > CRUD permissions. But could not have just the App permission without
> > having the permission to manipulate the graph. It's like a OSGI bundle
> > that needs another bundle in order to properly work.
> >
> >
> > -----Original Message-----
> > From: Manuel Innerhofer []
> > Sent: Montag, 22. März 2010 15:13
> > To:
> > Subject: Permission naming convention for using an application
> >
> > Hi all,
> >
> > Reto and I have discussed how to name permissions that gives a user
> > permission to use an application front-end. This means even though the
> > user has all permissions needed to use the functionality provided by the
> > application (like modifying a graph etc.), she still can't access its
> > front-end.
> >
> > We came up with the convention that the permission name should end with
> > "AppPermission". For example the permission needed to access the script
> > manager has the name "ScriptManagerAppPermission".
> >
> > Cheers,
> > Manuel
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message