GNOME Bugzilla – Bug 441839
ACL setup broken
Last modified: 2018-09-24 10:05:56 UTC
The setup of ACLs in the wiki is broken. I tested this with http://live.gnome.org/TestPage and Ken VanDine was also able to change his ACLs: http://live.gnome.org/KenVanDine But then was not able to remove it again. This means that ACL admin setup is wrong. Supposely all users may change ACLs which should not be the case. What has to be done to fix: * Remove ACLs from TestPage, TestPage2 and KenVanDine * Look at the moin config files. Especially what it says who may "admin". * Change config so that only people in AdminGroup may change ACLs * then explicitly add groups or people to AutoAdminGroup if you want groups or people to admin some spaces without AutoAdmins interaction.
I do not see the problem of allowing people to add ACls.
Well it means that the whole wiki can be blocked by one user. This is like you allow everybody to set access rights to gnome.org server discs. Ken can not access his page, nor anybody else. Somebody with more rights should solve this problem. If anybody can set ACLs it also makes not much sense. Generally one would want some groups to set their rights to some pages and not everybody users to change access to the pages of one group. This is also good for users to protect them from changing ACLs accidently. This can result in more activity for the server admins to fix wrong acls, because once set they can not be changed. The thing is that although user can set ACls they are not superusers and so they are affected by acls.
I still do not see the problem. Any user can change the whole Wiki. I do not see the problem of allowing people to use ACLs. Yes, they should not make mistakes in doing so. The intention is that anyone can set ACLs. Preferrably only ACLs that result in pages they can still access. The admin bit is IIRC only set as default (when there isn't another ACL set). This allows e.g. GNOME Mobile to put their pages on the wiki without needing sysadmins for every page. This without granting people to see/change every page irrelevant of the ACL that was set (e.g. I do not want more than a few people to be in AdminGroup). What is the difference between AutoAdminGroup and AdminGroup btw?
First it is important to understand that there are two right levels: a) General rights: "read,write,revert,delete,..." (access rights) b) Admin rights: "admin" ( Admin does not give you any more general rights, the term in this context is just related to "#acl" lines - admin rights) Generally the auto admin system is like this: * You have a list of groups and users in AutoAdminGroup. This group means "These groups or users should be allowed to change the "admin" rights on their own pages. With your example of GNOME Mobile you would have in AutoAdminGroup: * GnomeMobile/AdminGroup And this then contains users that may change the acces rights of GnomeMobile/* The AdminGroup is another level (similar to the superusers) that may set rights everywhere. So you have a hierarchie like: 1. Superusers (may do everything) 2. Admins (may change ACLs on every page and by default may read,write every page) 3. AutoAdminGroups Admins (Users who change access to the admin page or remove and add users to the group (so not everybody can remove write access to GnomeMobile/AdminGroup, so this page should not set admin rigths to that same page to the group but rather to project leaders, otherwise every member could exclude the project leader from the group) 4. Project Members (in list on GnomeMobile/AdminGroup) can be added or removed to and from a group. They are given the rights to admin so they are able to set admin rights 5. Registered users (Group name: Known) 6. All users including anonyous (Group Name: All) The current set up is that Registered users have the same rights as 2. Admins - with the only difference that Admins like you can access a page even if the ACL of that page does not inclusively name you OlavVitters to be able to access the page. So what GNOME rather would want to do is to have a hierarchical system where members o the admin group have write access to AutoAdminGroup (you can also add other groups or users to the pages acl to help you in the this task). So a new group would contact somebody who may define new groups which means give them the right to admin themselves (add/remove new members, set ACLs on their sub pages). Another thing to watch is that all pages under GnomeMobile have a standard header, which you can ensure by creating a template with a #acl line and maybe also a form field for page creation. Another thing that one can do is to create two standard sub pages: + /ReadGroup (who may read every sub page with standard rights) + /ReadWriteGroup (who has write access on every sub pages. If only some people should be able to create new sub pages you want to make this clear here) These /AdminGroup and /Read.*Group are not related. But you can use the AdminGroup to define who may add/remove people from or to these pages. Hope that explains it some more. I think if set up correctly the users will not have to understand all this as they just get the rights they need. But the admin stuff should be set up more complex and in a way that it does not have any negative effects.
Can someone at least remove that ACL from my page? I only added it to test something for Thilo, now it isn't accessible. http://live.gnome.org/KenVanDine
... and remove http://live.gnome.org/TestPage
Created attachment 119890 [details] [review] remove admin rights This patch removes the admin rigths from the moin configuration to make sure nobody can block pages.
I dont know if the module "wiki-web" on SVN is the actual module for the live.gnome.org wiki, but if it is many things would need fixing. As a start I have a fix for this bug which is very simple. Just remove the "admin" right for everybody. Only people who are part of an admin group should have those rights.
somebody who may, should remove: http://live.gnome.org/TestPage http://live.gnome.org/TestPage2 It seems this is still buggy, because I was able to create http://live.gnome.org/TestP with admin rights but now I can not read it. I added "#acl ThiloPfennig: read,write,revert,delete,admin" Not sure, but maybe the space between ":" and "read" was the problem. Anyway, this should not happen, because as far as I know I am not in any admin group. Just to point that out: This is a security vulnerability, known since at least May 2007! Increasing importance, because until now it was ignored.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/Infrastructure/Websites/issues/8.