Open Source Document Management System | OpenKM

Hi to all I will report a bug that I found in OpenKM demo (demo.openkm.com)
A user with security permissions can remove 'ROLE_USER' from the roles allowed even if this implies that it can't see the folder anymore.
This causes the system to display some errors like 'the path does not exists' on the folder with modified permissions.

To test:

go to a folder different from root
click on tab security
click update
go to roles
remove 'role_user' role
click close
try to visualize something in that folder
the system says 'path not exists'

If I understood you remove yourself grants from a folder no ? then obvisously you'll get path not exists because without grants in than folder any file into etc... will not exists for you. I do not understand exactly the problem, really systems acts correctly, you have removed grants to your user and automatically you can see that path ( in the same way consider that you're on multi-user scenario and this operation can be done in same way by other user, you're seeing some document or folder and other user removes grants to you, automatically you'll get this kind of error, this is correct ).

From an usability point of view this is wrong.
An user hasn't practice with permissions and often does not undestand the consequences of removing a role.
What the user see is a folder that before was there, and after a click a series of error arises saying that that folder does not exist anymore.
The base user will think that the folder was removed or that this is a bug (because that folder was here just a second before!).

Also this can create "stale folder" problems:

maybe there exist a folder that can't be seen by anyone except the ADMIN_USER ..
Users unable to access anymore to that folder will try to recreate it, and another error will arise "folder exist"
this is kind of contraddictory, because the system just little before said that the folder does not exist..

In the patch I posted here
http://issues.openkm.com/view.php?id=2414

if an user tries to remove himself the rights to see a folder an adequate error message will be displayed.

I do not like much this kind of intervention, I think in my opinion always is better if is done some mistake call administrator ( exists for some reason ). In other hand if user wants to remove himself and other users ( because have same privileges ) from node it'll be not possible without ROLE_ADMIN grant. Some logic is great to solve problems, but it other hand non human intervention and let all in logic could be a problem ( I'm not sure if it could be the case, but after 10 years talking with users one observates that my logic not always is the general, at least there's not only an absolute logic that will be pleased for everyone ).

Anyway I would like to understand the logic to decide when user removes some grant is right or not. For example supose this scenario:
User is called test:
User has roles: ROLE_USER, ROLE_X1, ROLE_X2, ROLE_X3
Folder has grants by roles: ROLE_X1, ROLE_Y2, ROLE_Y
Folder has user grants: test

Here are several scenarios possible, are several order way to removes roles and users. Imagine you do not have write access and change secutiry access for all roles or users. Depending the order you're trying to remove and evaluate you'll get some problem. Are you evaluating get read acess, write access and change secutiry before doing any operation ? If you doing it this way ( is needed otherside logic will not be right ) you should raise a new type or error ( you're not allowed to remove access to this node ).

In other hand imagine that you have read, write, security grants. What happens if you remove only one ( you consider this case too ). Sincerally I think is a very complicated logic ( if you implemented correctly, I suppose yes ) for the result. Security grant from my point of view should be only given to a few users, really can be done some automation utility that if user is not in some role etc.. .automatically after creating folder, doc etc... removes this grant.

Last years our maximum was "If is not easy it no well done solved, stop and think again. You not see clearly ? take your time and turn back again morelater." Do not angry with me. Sincerally we're happy with your source code support, but I know in deep source code and this feature seems to be a candidate to be implemented on a complex logic ( or several ).

I know what you mean: the error messages are contradictory because the folder "does not exist" but "also exist". Perhaps your approach is more consistent because an user should not remove privileges from himself (I think it has little sense).

But from another point of view, If another user remove this revoke this read permission the other user also will have the same problem: he can't see the folder but it really exists. What is your proposal in this scenario?

Edit: Perhaps the problem is the error message "the path does not exists" and should be "read access denied" (or something like this), isn't it?

First of all I would like to point out how my implementation works:
the idea is that a user, even if it has security permissions, cannot remove to himself the rights to read a file/folder.
It can remove the rights to update security, to write/delete but not to read.

I've done it this way because imho the user should not have the possibility to do something harmful.
Think about an user that uploads a file, and then changes its permission to add some group.
It can by chance remove the 'role_user' group (button add/remove are very near..).
Then immediately the error 'file does not exist' appear, and ALL the users can't see this file (even if it is there!) anymore.

What do you think a user should do at this point? It is not going to call the administrator..
In my opinion a normal user will think that it hasn't uploaded the file correctly, or that there is some bug in the system and will try to upload the same file again, getting the error 'file exists'.

pavila wrote: But from another point of view, If another user remove this revoke this read permission the other user also will have the same problem: he can't see the folder but it really exists. What is your proposal in this scenario?

Edit: Perhaps the problem is the error message "the path does not exists" and should be "read access denied" (or something like this), isn't it?

In the scenario you proposed,
if the user who tries to remove the rights is an administrator, he can do it (because he can still read that folder) the other users with the rights just removed will not see the folder.
If the user who tries to remove this rights is an user with security perms, he can remove all the perms except the read one.
If he tries to remove the read permission, a popup 'accessdenied' appears that contains the error: "You can't remove role X from folder Y, because this will disalow your user to see this folder".
(the error message can be improved..)

In every case, if then an user that can't see that folder tries to create a folder with the same name will get a 'folder exists' error.
Maybe we can change that error message discriminating the case in which a folder exists and is visible (that will raise 'folder exists')
and the case in which the folder exists but is not visible (that will raise some other well thought error..).

The confusion here lies in the fact that in OpenKM the 'read' permission, is a 'see' permission.
In linux if an user can't 'read' a folder, it will get access denied only when it tries to see what's inside, but it can see the folder.

Still I do not propose to follow the linux implementation (the fact that certain folders can be hidden is nice in my scenario, because each folder correspond to a different project and the administrator of a project should not see the other projects).

It's something to think with pacience ( each time I add some restriction then somebody want to remove it, your expositions seems right ).

I will explain a real case. Several users ( different companies ) upload files on same folder. But after uploading should not see the file. This is a strange case too - but real - done with automation fesature, internally after document uploaded grants are removed ( effect to end user is document is not seen although UI tells him has been uploaded, not receives error because when is refreshing folder he has not grants to view it yet ). Obviously is not the same case you expose here, it's automatic internal feature, but it's real case that should continue running ( I think you've modified servlet not internal Auth api implementation no ? )

I've modified NodeBaseDAO.java
(because I saw that the access logic is implemented at that level)
is this wrong?

Regarding the automatic routines,
I think that someone that is given with the ability to inject a turing complete language into a program can crash it no matter what are the restrictions.
Users who want to put scripts inside OpenKM should be aware of that, and have to pay attention on what they do.

OpenKM developers cannot think in advance to each possible mistake a script can do... because of Rice theorem.

Modification in XXBase.java extends to all api, that means a user can not remove grants himself from automation actions too. We need thinking on it I do not want to say is wrong simply has colateral effects and should be evaluated if we make some minimal change with configuration property ( to switch enable / disable )

Let the user decide which is the wanted behaviour is probably the best option!

Of course, but sometimes the user don't understand the implications of some modifications and see the behaviour as an error.