On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)magelo.com> wrote:
Hello Vincent,
I understand what you are saying and I totally agree however there is a need to have a
fine line as to where everyone can go and can do.
And for sure, the line is different for a public wiki or an enterprise wiki.
With Mediawiki or Dokuwiki, I cannot delete a page which is not mine and I cannot change
the permissions of a page which is not mine.
Right now I can do both with Xwiki which imho is not an expected behaviour for a public
wiki.
You need delete right in xwiki to be able to delete a page too so that's not an
issue.
Of course one can argue than you can always edit and
leave the page blank but at least the history will be here and the page can be rollbacked.
And it's not as easy as just clicking a delete button.
When you delete a page in xwiki, it will delete everything associated with that page
meaning all the rights, the instances and the classes. Is there an history for all of
thoses ? I am kinda under the impression that only the content of the page is versionned
and can be rollbacked...
And it just does not make sense that anyone who can edit, can touch the rights at all and
to some degree, same goes for the instances. And again, unless I am wrong, you cant
rollback those…
You can rollback anything.
In order to secure things I want to hook into the
XWikiRightServiceImpl, but it does not seem to be used.
There's a new security module since 5.x:
See
http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module
Could you point me to the service that is responsible
for the authorizations/rights ?
Also if you could explain me how I can secure the HtmlMacro without touching its jar that
would be very helpful. From looking around and the discussion, I was under the impression
that it was possible but I just dont know how…
This is a work in progress. There's a pull request from Thomas Delafosse about this
but it's not been applied yet AFAIK.
BTW if you wish to report security issues and vulnerabilities the best is to use the
security mailing list and not the user or dev list since they're public, see
http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HPrivateMailingL…
Thanks
-Vincent
Thanks !
--
Chris
On 8/6/2013 16:30, Vincent Massol wrote:
> Hi Christian,
>
> On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier(a)magelo.com>
wrote:
>
> [snip]
>
>> Ya programming right cant be stolen that easily but you can do so much harm with
just the edit permission...
>> I can wipe out an entire wiki, I can deny pretty much anyone any page, create
abitrary instances of objects etc...
>> I cant even understand how people can use Xwiki for a public wiki, it seems so
easy to mess up the whole thing.
> [snip]
>
> This is exactly what a wiki is for: an easy site to modify content. The reasons wikis
are powerful is precisely because of that: low barrier to contribution and ability to
easily modify content.
>
> The promise of a wiki is that it's easy to rollback changes (easier than for
someone to deface it).
>
> You can find a lot of instances of public wikis on the web that work quite well. Just
to cite 3 public instances using 3 different wiki engines:
> * wikipedia (mediawiki)
> *
xwiki.org (xwiki)
> *
https://www.dokuwiki.org/ (for ex go to
https://www.dokuwiki.org/features and click
the edit pencil) (dokuwiki)
>
> Now obviously, for this to work you need community members that watch for vandalism
(
http://en.wikipedia.org/wiki/Wikipedia:Vandalism).
>
> But when you use a wiki, you want collaboration and this is small price to pay in
exchange. Obviously if your vandalism rate is higher than your contribution rate you
should ask yourself questions and take some actions! ;) But in general it's good to
keep things open till there are problems since closing things down will slow down
contributions.
>
> Now XWiki is more than a wiki and we need to address all use cases. We currently have
a contributor working 100% of his time on security aspects. He's made a lot of pull
requests recently; some have been applied and others are being reviewed. To answer one of
your point, we've identified the need to require some permissions for adding/modifying
some xobjects.
>
> Thanks
> -Vincent