Hi,
On Sun, Mar 9, 2008 at 2:20 PM, Vincent Massol <[EMAIL PROTECTED]> wrote:
>
> On Mar 9, 2008, at 9:04 AM, Guillaume Lerouge wrote:
>
> [snip]
>
> Given that I just recently registered and I'm not a "committer" (yet) I
> > assume I should not have programming Access rights. Unfortunately, it let me
> > perform the actions anyways as if I did have these rights.
>
>
> I think it's only a problem of display -> basically, you cannot create new
> jobs (this would add groovy code to the page and indeed require programming
> rights, which you do not have).
>
>
> I've checked the scheduler code quickly and it doesn't check for any
> right. I think the assumption is that if you want to secure the Scheduler
> pages you'll do this by securing the Scheduler space or individual pages.
>
> I think the rationale is that some people will want to have different
> rights for their scheduler feature.
>
> However I think I agree in that we should only allow non read actions to
> admins by default.
>
> WDYT?
>
This sort of functionality (or a safeguard in a sense) is also present in
default mysql installation where 4 default accounts are created without
passwords (i think 2 accounts with 'root' username and two accounts with
empty username). The idea is to get the user to read the manual and make
his installation secure by himself.
I'm not sure whether i'm correct with this argument, but it feels like this
is something that has to be left as it is. ( Moral : read the docs! )
Thanks.
- Asiri
>
> Thanks
> -Vincent
>
> However, there must be a missing check before the button you hit
> (something akin to #if ($xwiki.hasAccessRight('program') == 'true') button
> #end). So this is a bug in the watchlist application rather than in the
> rights setting of the wiki.
>
> I think that had you tried the .../bin/delete/... URL you would have
> received a "you do not have the rights to perform this action" message. In
> the worst case, the page wouldn't have get lost thanks to the recent restore
> page feature ; -)
>
> *<snip>
> >
> > *This is despite the printed warning at the bottom of the page:*
> > *"Job creation is reserved for programmers. It seems you do not have
> > programming access right allowed on the Scheduler space."
>
>
> The last version of the watchlist was released a few days ago, meaning
> there is probably some testing remaining. Please report this bug in JIRA (
> http://jira.xwiki.org/) so that it can be fixed by the watchlist app
> developer.
>
> Xwiki.org <http://xwiki.org/> says it's running "1.3-rc-1.8082"
> > ---------------------------
> >
> > This leads me to wonder how such administrative functions are secured.
> > It makes sense to condition presentation of pause/delete/unschedule
> > /schedule
> > on whether Administrative/programming-access is available to the
> > logged-in user. (i.e. don't present UI capabilities which aren't
> > accessible to the given login/role).
> > However, if someone were to just enter the URL
> > http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler.WatchListJob4the
> > action should be access-controlled and prevented anyways. In my case, it
> > wasn't.
> >
>
> We absolutely agree on this. Most of the time XWiki has script that checks
> the user rights prior to displaying specific parts of the UI (for instance
> on the topbar menu -> the menu is not the same depending on the user being
> logged in as a reader, an admin...)
>
> Anyways, sorry about doing this by accident. Hopefully no damage was done
> > (I did resume the job i paused).
> > I assume this is a "bug" I've discovered, and not a "feature."
> >
>
> Then it means you'll have the joy and priviledge of playing with our JIRA
> instance soon ;-)
>
> I guess further explorations in this area should be done on my own
> > instance rather than xwiki.org ....
> > ( no, i didn't test "unschedule" or "delete" given the potential that
> > they'd actuallty work).
> >
>
> Thanks ! :-) If you really want to test XWiki online you can use
> http://playground.xwiki.org/xwiki/bin/view/Main/ instead (it's almost
> always running on the latest version of XWiki)
>
> If this is a bug, it would probably make good sense to review other
> > instances where this might happen (aka "security walkthrough" of code).
> > Is there any automated functional testing of the entire system (as
> > opposed to unit testing) to ensure such access control issues aren't lurking
> > in other areas?
> >
>
> We're always working on adding new tests. Your help would be greatly
> appreciated in this area should you have the possibility to write some of
> them. I'll let someone else tell you whether this one in particular already
> exists.
>
> -- Niels.
> > http://nielsmayer.com
> >
> > PS: Is there a document describing the security architecture of Xwiki?
> >
>
>
> I didn't found it on XWiki.org, meaning someone will have to write it. If
> you feel like it, you can start one at
> http://dev.xwiki.org/xwiki/bin/view/Drafts/ if you want to.
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
