28 Jun
2015
28 Jun
'15
12:24 p.m.
On Sat, Jun 27, 2015 at 10:51 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
I am convince that we should rely on the current model, and the current
abilities of the model to provide a proper security solution. If we start
using tricks, it is the open door for security holes.
Not necessarily true, since we have the CREATOR right, which actually only
implies DELETE at document level and undeniable, we may surely extend it to
also implies VIEW and EDIT, so it given creator a more consistant right on
their own page. Now if that document is non-terminal, the global rights
that we set on it will still depends on WebPreferences, and actually those
documents are not editable by non-admin users.
This already what we have with spaces, user are not able to create private
spaces unless these user are admins. This could be seen an unacceptable
limitation, but counter proposal need thorough reflexion and I am not sure
it is the right time of it at the moment.
I really do not like such change. If we would go for it, I would use
separate documents to store objects that needs different levels of access.
So this could means extracting global rights objects into another document
than WebPreferences, and allowing EDIT rights to those that are allowed to
edit permissions. Once again, I will be very careful with any proposal that
do not exploit the actual model and security module to complete right
purposes, since, this has been prove bad in the past.
On 27 Jun 2015 at 10:29:00, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
Sorry, but either I do not understand or it looks too complicated for end
users.
On 26 Jun 2015 at 18:26:11, vincent(a)massol.net
(vincent(a)massol.net
(mailto:vincent@massol.net)) wrote:
> One item we haven’t discussed here again (it was discussed in some
other
thread) are the Permissions.
>
> When we have ND, we need to decide how to set permissions for a
non-terminal
page.
>
> Here’s what I propose:
>
> * Remove the current “Edit Rights” menu entry and replace that with an
“Administer page” menu entry, see
http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration .
Ask for Admin rights to be able to go to the admin UI.
> * When on a non-terminal page (i.e. a
WebHome page), go to the “Space”
Admin UI when clicking “Administer page”
> * When on a terminal page, go to the Page
Admin UI (
http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration)
when clicking “Administer page”
> * Add a,
xobject listener (or some other way) to prevent users without
admin rights to be
able to add a Rights XObject
>
> Note that one use case that would be nice to support is the following:
> * You create a page A
> * Some other persons create pages B, C, having your page A as parent
> * You change the permissions on page A to allow only yourself to view
it (or
edit it)
> * Suddenly people who had the rights to view
or edit pages B and C
don’t have them anymore.
>
> OTOH with my proposal above you wouldn’t be anymore to have private
pages
(unless you have Admin permissions). Is this acceptable? If not, do
you have a counter proposal?
A counter proposal would be to introduce a Permissions to control
Permissions.
This is probably what would be the more flexible and would
allow for all use cases.
We would still need to decide if we want to use the page level permission
or the space level one when on a non-terminal page. Ideally it should be
the space level UI IMO since it has more features (hence my initial
proposal above). However, since we may want to retain the ability for a
user to edit permissions, we could allow users with
the “Permission” permission to go to that Admin page but only be able to
modify permissions while requiring Admin permissions to modify the other
options of that page.
WDYT?
I am sorry not to have more time at the moment for a complete counter
proposal, but I hope the above remarks will be helpful.
Thanks,
--
Denis Gervalle
SOFTEC sa - CEO