Web Images Videos Maps News Shopping Gmail more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion Security branch (merge to trunk?)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Alec Thomas  
View profile  
 More options Jan 13 2007, 3:31 am
From: Alec Thomas <trac-dev-l...@swapoff.org>
Date: Sat, 13 Jan 2007 19:31:08 +1100
Local: Sat, Jan 13 2007 3:31 am
Subject: Re: [Trac-dev] Re: Security branch (merge to trunk?)

On Thu, Jan 11, 2007 at 05:36:01PM +0100, Christian Boos wrote:
> In particular, I'd like to see how we'll convert the attachment module,
> in a way that would allow generic attachments (see #3068). This
> shouldn't require any additional interface (i.e. /not/ the
> IAttachmentPointProvider way) but should result from the ability to add
> attachment to any kind of resource (this doesn't mean we'll add an UI to
> do this for every kind of resource!).

After contemplating this for a while, I think the most elegant solution
is to add an _ATTACH permission. This makes more sense anyway, IMO, as
attaching something to an object is distinct from MODIFYing it.

So there could then be WIKI_ATTACH, TICKET_ATTACH, MILESTONE_ATTACH,
etc.

----------- Future rant -------------

Once the permissions are more uniform, we can begin removing the
reliance on having a permission for each action on each object and move
to a small set of permissions:

    VIEW
    CREATE
    DELETE
    MODIFY
    APPEND
    ATTACH
    GRANT (maybe? for allowing a user to grant other users non-ADMIN permissions)
    ADMIN (all of the above)

Here's a patch: http://swapoff.org/files/new-permissions.diff. This
converts the wiki module to the new permission system, but also adds a
LegacyPermission component for backwards compatibility, which simply
maps all the new style permissions with `realm.upper() + '_' perm`.

The only slight "wart" is that the module itself defines the
permissions, even of things like ATTACH which perhaps should be defined
in other modules, but perhaps not. I think this is difficult to avoid
though, because the attachment module and its parent are co-reliant.

--
Evolution: Taking care of those too stupid to take care of themselves.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google