[xwiki-users] Bug: create/delete wiki rights from account not named "Admin"
In setting up our XWiki farm, I came across a couple of bugs. In general, should we always bring up bugs on the mailing list first before entry into jira? I deleted the account named "Admin" after setting up other individuals as administrators. A user with "admin" rights (or even "delete" rights) could no longer create or delete wikis from the "wikis" page of the XEM. However, if I recreated an account named "Admin", then a user with "admin" rights *could* create/delete wikis from that page, even though they're not logged in as user "Admin". The rights checking on that page must be hardcoded to check if user "Admin" has the rights, instead of checking the user who's actually logged in and making the page request. XEM 1.9.3 Trevor
Hi Trevor, On Mon, Aug 24, 2009 at 5:06 PM, Trevor <[email protected]> wrote:
In setting up our XWiki farm, I came across a couple of bugs. In general, should we always bring up bugs on the mailing list first before entry into jira?
I deleted the account named "Admin" after setting up other individuals as administrators. A user with "admin" rights (or even "delete" rights) could no longer create or delete wikis from the "wikis" page of the XEM. However, if I recreated an account named "Admin", then a user with "admin" rights *could* create/delete wikis from that page, even though they're not logged in as user "Admin".
The rights checking on that page must be hardcoded to check if user "Admin" has the rights, instead of checking the user who's actually logged in and making the page request.
XEM 1.9.3
That's most probably due to a programming rights issue. In XWiki, certain pieces of code (namely Groovy code) can be executed only if the last user to have saved the document where such code is stored has programming rights. This is to prevent arbitrary code execution and privilege escalation in the wiki. If I'm correct, all you need to do after deleting the "Admin" account is to save the page where the Groovy code is stored with one of your other admins, after making sure that admin has the programming right set as true at the global level of your farm. We're aware that the way this mechanism works is not ideal in cases such as yours and we'll fix its logic at one point, but for the time being that's how things work. So it's not quite a bug but I agree there's room for improvement. As for discussing issues on the mailing lists before posting on JIRA, well, the discussion will take place in JIRA comments if it has to anyway ;-) Thanks for your feedback, Guillaume
Trevor _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Trevor, I just want to complete what Guillaume had said. For any documents it exists 2 authors: - the last _author_ of the document, the one that have saved any information into the document - the last _content author_ of the document, the one that have saved the _content_ of the document The first one is show in the about div at the bottom of each document, the second one is very hidden and could only be checked in an XAR export, a raw XML view of the document or using code. For some operations, like accessing the internal privileged API from velocity or running groovy scripts, the _content author_ of the document containing the (velocity) code (or the one your are looking at for groovy) should have programming rights. Currently, with the new rendering engine, the document on which the content author is checked is always the document your are looking at, not necessarily the one that directly contains the code. This should be improved later, when the new 2.0 macros received more context information. Therefore, the rights to do an operation has usually nothing to do with the programming rights of the currently connected user. AFAIK, there is almost no case where the currently connected user is check against programming rights in a standard XWiki. So most of the page of a basic XWiki does not require such rights, some does. And due to the way new wikis are setup, generally by an import procedure, there may be additional issues, regarding programming rights: - most pages has XWiki.Admin as content author at initial stage - in a farm, those having XWiki.Admin as content author in another wiki than the main one, does not have programming rights (XWIKI-4066) - importing non-backup pack does not help in fixing content authors (XWIKI-3725) So this is currently a bad idea to remove XWiki.Admin, and I generally change its password to some random one for securing that somewhat internal account. As Guillaume said, there is room for improvement: - ensure proper context for 2.0 macros (in progress I think) - ensure better support of content authors during import (XWIKI-3725, XWIKI-4066, XWIKI-4073) - allow importing backup pack (like the XWiki provided ones) as non- backup one, this would allow importing non-backup pack with another admin as content author - it could also be useful for admin to see who is the content author more easily, since there is no interface showing them Hope that this will help you understanding potential programming issues. Regards, Denis On 24 août 09, at 17:37, Guillaume Lerouge wrote:
Hi Trevor,
On Mon, Aug 24, 2009 at 5:06 PM, Trevor <[email protected]> wrote:
In setting up our XWiki farm, I came across a couple of bugs. In general, should we always bring up bugs on the mailing list first before entry into jira?
I deleted the account named "Admin" after setting up other individuals as administrators. A user with "admin" rights (or even "delete" rights) could no longer create or delete wikis from the "wikis" page of the XEM. However, if I recreated an account named "Admin", then a user with "admin" rights *could* create/delete wikis from that page, even though they're not logged in as user "Admin".
The rights checking on that page must be hardcoded to check if user "Admin" has the rights, instead of checking the user who's actually logged in and making the page request.
XEM 1.9.3
That's most probably due to a programming rights issue. In XWiki, certain pieces of code (namely Groovy code) can be executed only if the last user to have saved the document where such code is stored has programming rights. This is to prevent arbitrary code execution and privilege escalation in the wiki.
If I'm correct, all you need to do after deleting the "Admin" account is to save the page where the Groovy code is stored with one of your other admins, after making sure that admin has the programming right set as true at the global level of your farm.
We're aware that the way this mechanism works is not ideal in cases such as yours and we'll fix its logic at one point, but for the time being that's how things work.
So it's not quite a bug but I agree there's room for improvement.
As for discussing issues on the mailing lists before posting on JIRA, well, the discussion will take place in JIRA comments if it has to anyway ;-)
Thanks for your feedback,
Guillaume
Trevor _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
participants (3)
-
Denis Gervalle -
Guillaume Lerouge -
Trevor