You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Claus Köll (JIRA)" <ji...@apache.org> on 2007/07/05 10:31:04 UTC
[jira] Created: (JCR-1005) More Fine grained Permission Flags
More Fine grained Permission Flags
----------------------------------
Key: JCR-1005
URL: https://issues.apache.org/jira/browse/JCR-1005
Project: Jackrabbit
Issue Type: Improvement
Components: security
Affects Versions: 1.3
Reporter: Claus Köll
It would be fine to have one more Permission Flag on node add.
At the moment there are 3 flags. We need to know if a node will be updated or created.
This is not possible with the current implementation because on node add the permission flag
AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
he can because the same PermissionFlag will be used.
Maybe there is a other solution for this problem ?
BR,
claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1005) More Fine grained Permission Flags
Posted by "Claus Köll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518721 ]
Claus Köll commented on JCR-1005:
---------------------------------
thanks for your hints stefan
ok i see my patch was too fast. sorry that it is not complete
i also thought that there is maybe a problem with backward compatibility, but i have the problem as described
and maybe there is a other solution ?
you say that the current flags apply to the target and not to the parent but in the SessionImpl Method checkPermission()
there is my problem. In my scenario the user trys to add a new node (File->Save As) on a parent node and i should now
if he try to save the original file or if he try to save the file with a other name ....
/**
* "add_node" action:
* requires WRITE permission on parent item
*/
if (set.contains(ADD_NODE_ACTION)) {
try {
parentPath = targetPath.getAncestor(1);
parentId = hierMgr.resolvePath(parentPath);
if (parentId == null) {
// parent does not exist (i.e. / was specified), throw exception
throw new AccessControlException(ADD_NODE_ACTION);
}
accessMgr.checkPermission(parentId, AccessManager.WRITE);
} catch (AccessDeniedException re) {
// otherwise the RepositoryException catch clause will
// log a warn message, which is not appropriate in this case.
throw new AccessControlException(ADD_NODE_ACTION);
}
}
hope for help
claus
> More Fine grained Permission Flags
> ----------------------------------
>
> Key: JCR-1005
> URL: https://issues.apache.org/jira/browse/JCR-1005
> Project: Jackrabbit
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3
> Reporter: Claus Köll
> Attachments: acces.patch
>
>
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission flag
> AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
> try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1005) More Fine grained Permission Flags
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518708 ]
Stefan Guggisberg commented on JCR-1005:
----------------------------------------
first of all thanks for the patch!
i have the following concerns regarding the patch:
- the permission constants READ, WRITE and REMOVE are bitmask flags,
i.e. any new constant would need to be a power of 2
- the current flags apply to the target, i.e. WRITE permission on the node to
be modified etc. the new constant ADD refers to the parent of the target
which seems to be inconsistent.
- the patch is incomplete. it doesn't cover all locations that check permissions.
check for usages of AccessManager.isGranted()
- i am afraid that the proposed change wouldn't be backward compatible
with existing AccessManager implementations
cheers
stefan
> More Fine grained Permission Flags
> ----------------------------------
>
> Key: JCR-1005
> URL: https://issues.apache.org/jira/browse/JCR-1005
> Project: Jackrabbit
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3
> Reporter: Claus Köll
> Attachments: acces.patch
>
>
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission flag
> AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
> try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1005) More Fine grained Permission Flags
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519984 ]
Stefan Guggisberg commented on JCR-1005:
----------------------------------------
> there is my problem. In my scenario the user trys to add a new node (File->Save As) on a parent node and i should now
> if he try to save the original file or if he try to save the file with a other name ....
if the user saves the original file the parent node shouldn't be modified; OTOH if he saves the file with a new name the parent node will be modified.
> More Fine grained Permission Flags
> ----------------------------------
>
> Key: JCR-1005
> URL: https://issues.apache.org/jira/browse/JCR-1005
> Project: Jackrabbit
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3
> Reporter: Claus Köll
> Attachments: acces.patch
>
>
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission flag
> AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
> try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1005) More Fine grained Permission Flags
Posted by "Claus Köll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Köll updated JCR-1005:
----------------------------
Attachment: acces.patch
A patch that would help me.
Hope somebody will look at and comment it ...
> More Fine grained Permission Flags
> ----------------------------------
>
> Key: JCR-1005
> URL: https://issues.apache.org/jira/browse/JCR-1005
> Project: Jackrabbit
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3
> Reporter: Claus Köll
> Attachments: acces.patch
>
>
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission flag
> AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
> try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1005) More Fine grained Permission Flags
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-1005.
-------------------------
Resolution: Fixed
Fix Version/s: 1.5
i guess this issue has been addressed already some time ago with the overall security rework related to JCR-1588
> More Fine grained Permission Flags
> ----------------------------------
>
> Key: JCR-1005
> URL: https://issues.apache.org/jira/browse/JCR-1005
> Project: Jackrabbit
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3
> Reporter: Claus Köll
> Fix For: 1.5
>
> Attachments: acces.patch
>
>
> It would be fine to have one more Permission Flag on node add.
> At the moment there are 3 flags. We need to know if a node will be updated or created.
> This is not possible with the current implementation because on node add the permission flag
> AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and
> try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name
> he can because the same PermissionFlag will be used.
> Maybe there is a other solution for this problem ?
> BR,
> claus
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.