9 Mar
2008
9 Mar
'08
12:13 p.m.
Hi,
On Sun, Mar 9, 2008 at 2:20 PM, Vincent Massol <vincent(a)massol.net> 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
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
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?
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…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs