Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-41499

users without "delete attachment permission" can delete attachment

XMLWordPrintable

      1. go to space tools > permissions and remove the permission of user X to delete attachments
      2. go to a page of that space which contains an attachment
      3. go to attachments (no "delete" link available )
      4. expand an attachment to see older versionns (including current version)
      5. for each version there is the possibility to delete it
      6. if you delete all versions - the attachment is gone

      This completely defeats the purpose of the 'delete attachement' permission

            [CONFSERVER-41499] users without "delete attachment permission" can delete attachment

            Scott Dudley [Inactive] added a comment -

            In hindsight, is this a possible duplicate of CONF-36745?

            Scott Dudley [Inactive] added a comment - In hindsight, is this a possible duplicate of CONF-36745 ?

            Scott Dudley [Inactive] added a comment -

            mtran@atlassian.com, it does not appear that this bug was fixed. in addition to the breakage on 5.9.10 reported above, I just tested this on the freshly-released 5.10.0 and it is not fixed there either. Users with space admin permissions can still delete attachment versions, despite not having Delete Attachment permission.

            Scott Dudley [Inactive] added a comment - mtran@atlassian.com , it does not appear that this bug was fixed. in addition to the breakage on 5.9.10 reported above, I just tested this on the freshly-released 5.10.0 and it is not fixed there either. Users with space admin permissions can still delete attachment versions, despite not having Delete Attachment permission.

            Scott Dudley [Inactive] added a comment -

            mtran@atlassian.com, this is marked as fixed in 5.9.8. Is this fix propagated to 5.9.10 too? I just tested on that version, but logging in as a user who has Space Administrator privileges but not Delete Attachment privileges, I am still able to delete individual attachment versions (even though I don't have the option to delete the main attachment).

            For example, the plugin descriptor in attachment-actions.xml from 5.9.10 still seems like it's validating against space-administrator permission and not delete-attachment permission. This descriptor is the same in 5.10-rc1 too:

                <web-item key="remove-version" name="Remove Attachment Version" section="system.attachment.history" weight="90">
        <label key="remove.name"/>
        <link>/pages/confirmattachmentversionremoval.action?pageId=$page.id&amp;fileName=$generalUtil.urlEncode($attachment.fileName)&amp;version=$attachment.version</link>
        <styleClass>removeAttachmentLinkVersion</styleClass>
        <conditions type="AND">
            <condition class="com.atlassian.confluence.plugin.descriptor.web.conditions.SpacePermissionCondition">
                <param name="permission">administer</param>
            </condition>
            <condition class="com.atlassian.confluence.plugin.descriptor.web.conditions.AttachmentDataStorageWhitelistCondition">
                <param name="type">filesystem,database</param>
            </condition>
        </conditions>
    </web-item>

            Scott Dudley [Inactive] added a comment - mtran@atlassian.com , this is marked as fixed in 5.9.8. Is this fix propagated to 5.9.10 too? I just tested on that version, but logging in as a user who has Space Administrator privileges but not Delete Attachment privileges, I am still able to delete individual attachment versions (even though I don't have the option to delete the main attachment). For example, the plugin descriptor in attachment-actions.xml from 5.9.10 still seems like it's validating against space-administrator permission and not delete-attachment permission. This descriptor is the same in 5.10-rc1 too: <web-item key= "remove-version" name= "Remove Attachment Version" section= "system.attachment.history" weight= "90" > <label key= "remove.name" /> <link>/pages/confirmattachmentversionremoval.action?pageId=$page.id&amp;fileName=$generalUtil.urlEncode($attachment.fileName)&amp;version=$attachment.version</link> <styleClass>removeAttachmentLinkVersion</styleClass> <conditions type= "AND" > <condition class= "com.atlassian.confluence.plugin.descriptor.web.conditions.SpacePermissionCondition" > <param name= "permission" >administer</param> </condition> <condition class= "com.atlassian.confluence.plugin.descriptor.web.conditions.AttachmentDataStorageWhitelistCondition" > <param name= "type" >filesystem,database</param> </condition> </conditions> </web-item>

            Maximilian Drentschew added a comment -

            Thanks, this is really good news.

            I can also confirm Scott's statement: it only happened for Space admins - thanks for letting me know.

            Maximilian Drentschew added a comment - Thanks, this is really good news. I can also confirm Scott's statement: it only happened for Space admins - thanks for letting me know.

            Minh Tran added a comment -

            Dear All,

            Our team verified this bug is present in 5.9.6 and 5.9.7. However the good news is that it is already fixed in 5.9.8 & 5.9.11
            So please upgrade your Confluence to those latest versions to have the fix

            Best regards,
            Minh Tran
            Confluence BugMaster
            Atlassian

            Minh Tran added a comment - Dear All, Our team verified this bug is present in 5.9.6 and 5.9.7. However the good news is that it is already fixed in 5.9.8 & 5.9.11 So please upgrade your Confluence to those latest versions to have the fix Best regards, Minh Tran Confluence BugMaster Atlassian

            Scott Dudley [Inactive] added a comment -

            maximilian.drentschew450416846, I think the "remove attachment version" feature may actually be conditioned on the user having "Space Administrator" permission.

            Scott Dudley [Inactive] added a comment - maximilian.drentschew450416846 , I think the "remove attachment version" feature may actually be conditioned on the user having "Space Administrator" permission.

            Minh Tran added a comment -

            Dear maximilian.drentschew450416846,

            Thanks for raising your question. The priority is carefully adjusted based on the severity of the security issue and this is defined across our products.

            Regards,
            Minh Tran
            Confluence Bugmaster
            Atlassian

            Minh Tran added a comment - Dear maximilian.drentschew450416846 , Thanks for raising your question. The priority is carefully adjusted based on the severity of the security issue and this is defined across our products. Regards, Minh Tran Confluence Bugmaster Atlassian

            Maximilian Drentschew added a comment -

            I do not understand why this bug has been downgraded in priority again. Please explain.

            Maximilian Drentschew added a comment - I do not understand why this bug has been downgraded in priority again. Please explain.

            Maximilian Drentschew added a comment - - edited

            Minh Tran: The priority of this bug has been reduced. However, I see it as a big security problem if you rely on attachments not being deleted by users without permission to do so. Essential data could be lost or manipulated by an illoyal employee in a company using Confluence to manage their documents. I would therefore see this bug as "critical"!

            Maximilian Drentschew added a comment - - edited Minh Tran : The priority of this bug has been reduced. However, I see it as a big security problem if you rely on attachments not being deleted by users without permission to do so. Essential data could be lost or manipulated by an illoyal employee in a company using Confluence to manage their documents. I would therefore see this bug as "critical"!

              Unassigned Unassigned
              87826d9b52c5 Maximilian Drentschew
              Affected customers:
              0 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: