User ACL for private page fails

The following ACL fails:

#acl MyUserName:read,write,admin,revert,delete All:

with the error "You can't change ACLs on this page since you have no admin rights on it!".

Steps to reproduce

1. Attempt to add the ACL above to a page where you have admin rights (for example, your homepage)
2. On save, the error will appear

Example

See above.

Details

This Wiki

Workaround

It's not a bug - the user must have global admin rights before he can add an #acl statement. For 99% of use cases, editing the configuration and adding +Known:admin to acl_rights_before will result in the desired behaviour.

Discussion

It may be significant that my homepage shares my user name. It's not.

This is maybe just a misunderstanding and configuration issue.

By default, nobody has admin rights in moinmoin, so nobody can change acls. You have to give yourself admin rights by using acl_rights_before in your config. After that, you can change acls (and even give other people admin rights by page acl).

That sounded reasonable, so I added the following to the config:

    acl_rights_after = u"+Known:admin"

However I still got the same error. This is because the default acl_rights_default already set the known user rights:

    acl_rights_default = u"Trusted:read,write,delete,revert \
    Known:read,write,delete,revert \
    All:read,write"

The Known: target in the default matches before my acl_rights_after, so the acl_rights_default line requires modifications:

    acl_rights_before = u"AnAdminAccount:read,write,delete,revert,admin"
    acl_rights_default = u"Trusted:read,write,delete,revert \
    Known:read,write,delete,revert,admin \
    All:read,write"

This change also worked (adding "+" to the groups in acl_rights_default, adding acl_rights_after)):

    acl_rights_before = u"AnAdminAccount:read,write,delete,revert,admin"
    acl_rights_default = u"+Trusted:read,write,delete,revert \
    +Known:read,write,delete,revert \
    +All:read,write"
    acl_rights_after = u"+Known:admin"

Maybe read HelpOnAccessControlLists again. I think your problem can be solve by using acl_rights_before only. You are doing it much to complicated and it is often not necessary to change acl_rights_defaults and even less often to change acl_rights_after. And please delete your stuff above after you have found the good solution.

Here's what I want:

• A admin account / group has universal rights, that override everything else. Thus, that line goes in acl_rights_before. I like to use a seperate account, for the same reason I don't use my root account unless I'm doing maintenance.

• For pages that have personal stuff on them, the creator or maintainer should be able to control access to the page. The use case for me is a page with gift ideas for friends and family, and I don't want them to see it and ruin the suprise, and I want them to be able to create their own similar pages. This requires admin rights, so I need a Known:admin or +Known:admin somewhere in the ACL list.

• The page should be able to override these admin rights. For instance, a user might want others to read or edit his homepage, but not delete, etc., but retain the additonal rights for himself. If +Known:admin is in acl_rights_before, then any known user that can edit can also change the ACL. So, if you want to grant others edit but not admin privilidges, then +Known:admin must be in acl_rights_default or acl_rights_after. If you deny others write access, then +Known:admin can appear in acl_rights_before.

So, for my strange wiki, I need to alter acl_rights_default. It may not have much practical use for public wikis, which would be prone to ACL abuse , but may be useful for intranet wikis, where you know who everyone is. My question is, what would it break if the default was:

    acl_rights_default = u"+Trusted:read,write,delete,revert \
    +Known:read,write,delete,revert \
    +All:read,write"

This is the regular default, but with +'s. If this was the default, then I could just add +Known:admin to acl_rights_after, and not mess with acl_rights_default. Would it create issues for other people's wikis?

I'll try to describe in a clear way what do you want and how that can be done:

1. You want full control on all pages
   • Use

acl_rights_before = u'You:read,write,delete,revert,admin'

1. You want certain users to have full control over their pages.
   • Put this on their home page:

#acl ThisUser:read,write,delete,revert,admin

• Note that ThisUser SHOULD know what he/she is doing, or the full control will become full failure to keep his stuff private.

No other change is needed, no change to acl_rights_default, no change to acl_rights_after is needed.

-- NirSoffer 2005-02-10 16:48:08

• I think he wants to grant Known users admin access ... -- AlexanderSchremmer 2005-02-10 18:02:43

  • I don't think he really wants to do that. Its just like giving root access to all users on a machine...

It's not quite like giving root access. It's more like declaring "this is all public space / wilderness - if you want to take posession of a patch of it, throw up your sign". That's not how most people view their wikis, but it's how I see my personal one. And it's not ALL public space - all the underlay pages would override this "public" access, through virtue of pre-existing ACL's without global write privlidges.

Yes, I could handle it on a page by page basis. But I'm trying to avoid a situation where I user tells me "Can you edit JohnSmithsSexDreams, so that I have ACL rights and can keep you from reading it?"

I'm afraid its not possible with current acl. If you want to have private space, you must give each page acl right for one user - with the user name. If you give Known admin rights, then all users will have admin rights on all pages, including other people pages. -- NirSoffer 2005-02-11 12:08:34

• Actually, didn't above just come to the conclusion that it is, in fact possible, by altering acl_rights_default and acl_rights_after? You add 'Known:admin' to acl_rights_after, add plus signs to the default, and then everyone can take possession of a page by adding

  #acl MyName:read,write,admin,delete All:

  That would tie the "ownership" of a page to the "who first added his own ACL to it", but that's sort of OK. If you don't want that, you could still use ["JohannesBerg/PluggableACLs"] and tie ownership of a page to the fact that it was created as a sub-page of the user's homepage. -- JohannesBerg DateTime(2005-02-11T16:27:43Z)

Giving ownership the the first user is not something you would like to do.

But what you can do with current system - is use a security policy class that give admin rights if the page starts with the user name. So if you are ThisUser, you will have admin rights for ThisUser, ThisUser/SubPage, ThisUser/SubPage/SubPage etc.

Save this policy.py module near your wikiconfig: policy.py

Now add this to your wikiconfig (don't forget to indent):

    from policy import SecurityPolicy

• This still allow user to register with any pagename (except system pages) as a user name, and then admin that page, even if you don't want this page to be admined by users. To get a complete solution, you will have to more programing then this 10 lines example. To have complete solution, I guess you will have to force all users to register special names, maybe Users/UserName or something similar.

  This example does not work with current 1.3.3 code since PageEditor is broken, ignoring SecurityPolicy when you save a page, and accessing page acl directly. This is fixed in patch-621. patch-621. See ../SecurityPolicyAdminIgnored

You can test the above security policy in my test wiki: register a new account, create a home page, set acl as you like on your home page or any sub page.

• -- NirSoffer 2005-02-11 16:41:20

Plan

• Priority:
• Assigned to:
• Status: no bug

CategoryMoinMoinNoBug