bugSamizdat - Bugs: bug #24157, adding/removing moderator role...

 
 

bug #24157: adding/removing moderator role requires command line access to sql - patch: set_moderator_status-0.1.1 [vs 080811-1]

Submitted by:  Boud Roukema <boud>
Submitted on:  Thu 28 Aug 2008 11:24:17 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 16 Apr 2009 09:23:19 PM UTC, comment #2:

In the latest snapshot (0.6.2.20090416-1 in Debian/experimental), I've addressed this issue. However, instead of a Web UI I've implemented a command-line tool, samizdat-role, which allows to grant and revoke role priviledges to/from members.

The reason for this is that a moderator, unlike unpriviledged member, is able to do considerable amount of damage to a site. This makes obtaining these priviledges desirable for malicious users. Making Web UI capable of granting these is a security risk: a bug in Samizdat code could then create an exploitable priviledge escalation attack vector. Restricting this sort of operation to command-line access mitigates this risk by allowing this operation only to actors who are capable of doing that anyway. To further strengthen this protection, I've changed database generation scripts to only grant SELECT access to Role table to Samizdat database user.

Dmitry Borodaenko <angdraug>
Project Administrator
Fri 29 Aug 2008 08:41:44 PM UTC, comment #1:

version 0.1.1 has DEBUG lines removed

(file #16390)

Boud Roukema <boud>
Project Member
Thu 28 Aug 2008 11:24:17 PM UTC, original submission:

PROBLEM: Requiring a sysadmin to intervene directly in the sql database, e.g. with psql, is surely less robust and user friendly to novice sysadmins that the old situation - having moderators in the config file. That doesn't mean we should revert to the config file method. However, until something elegant is implemented, we should at least have some less fragile method of adding/removing the moderator role of a member. i'm filing this as a bug because there's no point aiming at a package installable like apache with aptitude install samizdat and answering a few questions if sysadmin has to almost immediately learn how to interactively use an SQL type database.

SUGGESTED PATCH: In the interests of having a flat power structure at the top of the editorial hierarchy, a simple solution is to allow anyone with moderator status to add or remove the moderator status of any member. Thanks to the new structure with having the role of moderator (and potentially, other roles) in the database, this is not too difficult to do.

SQL CHANGE: To implement this patch you will need to do
e.g. with psql. If you don't want that, then comment out the unset_moderator option somewhere, so that only sysadmin can unset the moderator role by command line intervention.

TODO: i didn't try to implement the full preview/confirm structure in member_controller for the operation of setting/unsetting the moderator role - it's clear that in 20080811, the moderate method in member_controller has been partially converted for a general action, though it remains partly hardwired to the block/unblock action. However, i did implement inclusion to the moderation log, so if someone starts doing some setting/unsetting which is unacceptable to the group, then this will be publicly known and transparent, which IMHO was a higher priority.

TODO: i didn't try any system of relating block/unblock privileges and set_moderator/unset_moderator privileges. The problem is that if we decide that moderators cannot remove moderation privileges from other moderators, then they cannot remove moderators from anyone, since noone other than moderators has moderation privileges to remove! The alternative is to do what wikipedia does, but more transparently: have many levels of hierarchy of formal, technical power, where the process of moving up the hierarchy is itself maximally transparent and participatory, and processes exist for deciding when to shift someone from a higher to a lower level due to abuse of power, inactivity or some other reason.

COMMENT: This last TODO probably relates to a hidden problem in the indymedia network: although many participants claim to be anarchist and the stated ideals of the network are opposed to hierarchy, it seems impossible in practice to avoid at least some sort of conditional, rather than absolute, hierarchy. Pretending that no hierarchy exists is not a way of reducing its reality...

Boud Roukema <boud>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by angdraug (Posted a comment)
  • -unavailable- added by boud (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 16 Apr 2009 09:23:19 PM UTCangdraugStatusWorks For Me=>Fixed
      Open/ClosedOpen=>Closed
    Fri 29 Aug 2008 08:41:44 PM UTCboudAttached File-=>Added 080829_set_moderator_status-0.1.1.patch, #16390
      Summaryadding/removing moderator role requires command line access to sql - patch: set_moderator_status-0.1 [vs 080811-1]=>adding/removing moderator role requires command line access to sql - patch: set_moderator_status-0.1.1 [vs 080811-1]
    Thu 28 Aug 2008 11:24:17 PM UTCboudAttached File-=>Added 080829_set_moderator_status-0.1.patch, #16382

    Back to the top


    Powered by Savane 3.1-cleanup1