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]

Submitter:  Boud Roukema <boud>
Submitted:  Thu 28 Aug 2008 11:24:17 PM UTC
   
 
Category:  None Severity:  3 - Normal
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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

GRANT DELETE ON Role TO samizdat;

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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-04-16 angdraug StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2008-08-29 boud Attached 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]
    2008-08-28 boud Attached File- Added 080829_set_moderator_status-0.1.patch, #16382

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code