[MAGNOLIA-2903] activation: users having only write permission in a subpart of the hierarchy are not able to activate Created: 16/Oct/09  Updated: 23/Jan/13  Resolved: 11/Dec/09

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 4.1.1
Fix Version/s: 4.1.3, 4.2.2

Type: Bug Priority: Critical
Reporter: Philipp Bärfuss Assignee: Jan Haderka
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File activation_error_1.log     Text File activation_error_2.log     JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg     JPEG File screenshot-3.jpg     JPEG File screenshot-4.jpg    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

In the following line a temporary node is created in the root of the workspace (the node name is the uuid)

--> ReceiveFilter.importOnExisting(ReceiveFilter.java:420)

If a user cannot write to the root, but only to a sub hierarchy, he cannot create this temporary node.



 Comments   
Comment by Jan Haderka [ 09/Nov/09 ]

Done as of r29318 on trunk and as of r29342 on 4.1 branch.

Comment by Will Scheidegger [ 02/Dec/09 ]

Hm... This issue is marked as "resolved", but as you can see on the attached screenshot:

  • Mag 4.2.1
  • User cannot activate!
Comment by Will Scheidegger [ 02/Dec/09 ]

Screenshot showing that the bug still exists on Mag 4.2.1

Comment by Jan Haderka [ 02/Dec/09 ]

Could you provide the actual log file from public instance from the time when this happened? Also the export of ACLs for the user who was activating this would help. Thanks.

Comment by Will Scheidegger [ 02/Dec/09 ]

screenshot-2 shows the ACL for the usere where the error happens.

Comment by Will Scheidegger [ 02/Dec/09 ]

When changing the ACL to what is depicted in screenshot-3, the error message changes (see screenshot-4)...

Comment by Will Scheidegger [ 02/Dec/09 ]

screenshot-4: Error message when trying to activate a node with ACL settings as shown in screenshot-3

Comment by Jan Haderka [ 02/Dec/09 ]

Log file please! I don't need to see the error message in details, it was clearly visible on the original screenshot already. (tho I'll let you know when I need magnifying glass to read )
I need to see a stack trace.

Comment by Will Scheidegger [ 02/Dec/09 ]

Well, maybe you do need a magnifying glass because the two error messages are not identical as I mentioned in the comment when posting them.

But I'm now adding the logs... just give me a few seconds.

Comment by Will Scheidegger [ 02/Dec/09 ]

the first log file shows the error as it occurs with ACL settings in screenshot-2

Comment by Will Scheidegger [ 02/Dec/09 ]

The second error log shows the error as it occurs with ACL settings shown in screenshot-3 - somewhat less interesting since this was only a test to try to get around error 1

Comment by Jan Haderka [ 02/Dec/09 ]

The fix for the issue have been applied as of r29318, however it have been reverted by mistake during attempt to backport it in r29342, so this issue is not fixed in 4.2 nor in 4.2.1

Comment by Will Scheidegger [ 02/Dec/09 ]

Ah, I see. Well, let's correct the settings in this JIIRA issue and hope for a 4.2.2 soon then. Thanks for the info.

Comment by Jan Haderka [ 02/Dec/09 ]

Re-applied the fix in r30052 on trunk and in r30053 on the 4.1 branch.

Comment by Sean McMains [ 09/Dec/09 ]

This fix helps, but doesn't entirely fix the problem.

Consider a user who has read/write permissions to a page called "/mypage", but who doesn't have write permission for "/".

When he goes to publish "/mypage", ReceiveFilter tries to create a transient node adjacent to "/mypage" – called, for example, "/7375437e-e4e2-11de-b1fd-07ca068ca79b". Unfortunately, this user doesn't have write access at root, so this transient node can't be created, and the publish fails even though the user had permissions for the page he was trying to publish.

Comment by Will Scheidegger [ 10/Dec/09 ]

I guess the only way to do this is to activate these temp pages in the system context and then move them to the spot where they belong in the tree with the proper user credentials. If the second action fails then the user has no write permission there. In that case the activation process should fail with the corresponding error message and the temporary node in the root should be deleted again.

Comment by Jan Haderka [ 10/Dec/09 ]

It's tad more complicated then that, as we do not move the original node anywhere and security check needs to happen for all properties as well not just at the node level, but yeah, the temp node has to be indeed handled in system context.

Comment by Jan Haderka [ 11/Dec/09 ]

No longer storing temporary nodes in the website so no more permission issues at that.

Generated at Mon Feb 12 03:41:15 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.