Hi,
How can we know what the workspace is during a filter which runs before the request is parsed?
In each request the workspace could be different according to the URL structure (and some requests don’t belong to a specific workspace, for example /user - there is no way
to deduct what the workspace is in that case).
It sounds like we would have to re-implement the logic done by JAX-RS using @Path annotations and also to be aware of all possible URLs used by services in this filter (which
also prevents us from adding APIs which are not known when writing the code - for example if they’re added by dependencies which add modules that register new services).
In my opinion it would be easier to implement such logic in the place where we know which workspace/project we are trying to access, and it would be more secure to do the check
as close to the place we actually check the permissions (to avoid “forgetting” to do this check).
Since the workspace is available in the constructor of FSMountPoint, that class seems to be a pretty good candidate to add this check (of whether the user is a member of the
workspace), and hasPermissions method is the place where the permissions are actually checked, so it seems like the natural place to add this check.
As for other places in the code that check for workspace/developer permission, these places probably also have to be changed accordingly (to add this check).
Best regards,
Tal
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: יום ו 11 מרץ 2016 13:45
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Question about Uses, Roles and Workspace access
On Thu, Mar 10, 2016 at 12:52 PM, Cohen, Dror <dror.cohen@xxxxxxx> wrote:
Hi Sergei,
Yes, I understand that Che relies on only one user. And that in that solution that user is granted
all roles.
But, In real life,
The logic in
hasPermissions() will have to change, right?
Even if I grant my user only one role (workspace/developer), workspace membership needs to be checked
as well…
How do I make such extension?
I think you misunderstand my point.
Role workspace/developer is dynamic. It's set during request execution in Filter according workspace membership.
You don't have to override hasPermissions method. You have to implement request Filter and set roles in Context depends
on request and user membership
Regards,
Dror
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Thursday, March 10, 2016 12:02 PM
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Question about Uses, Roles and Workspace access
The basic idea for VFS permission implementation is to rely on user roles in EnvironmentContext
For Che we didn't much care about that. Since we think that only one local user is working on.
We granted him all possible roles.
In real life. You request authorization filter should put User roles in EnvironmentContext depends on userid ,
workspaceId and his membership status.
On Thu, Mar 10, 2016 at 10:27 AM, Cohen, Dror <dror.cohen@xxxxxxx> wrote:
Hi Sergii and Gennady,
We are using the default VFS implementation, without any extension. package che-core-vfs-impl.
To get contents of a file and update it (get/put)
When debugging Che, I'm looking at the method hasPermissions() in FSMountPoint in che-core-vfs-impl.
In this method, access is granted base on the user's "workspace/developer" role, without checking if
that user is a member of that workspace (he is not)
This is not Che single user, I have 2 user' each with his own workspace
Is there an extension for che-core-vfs-impl I need to use?
If you wish, we can have a short online session where I can show the debug flow.
Hope this helps,
Dror
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Wednesday, March 09, 2016 11:01 AM
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Question about Uses, Roles and Workspace access
Hi Dror,
Let me refine Sergey's question to make it easier for you to answer.
Are you using default Che bundle to test?
(If so, indeed User is taken as workspace/dev and admin for all the workspace since Che is single user.)
On Wed, Mar 9, 2016 at 10:53 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Hello Dror
On Tue, Mar 8, 2016 at 2:55 PM, Cohen, Dror <dror.cohen@xxxxxxx> wrote:
Hi,
Yes, Version 3.14 I believe…
Yes, Exactly right. In debug I see that he is granted by the 'workspace/developer' role, although not
a member of that workspace
Can you elaborate a bit more. Where you can see it?
Dror
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Tuesday, March 08, 2016 1:30 PM
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Question about Uses, Roles and Workspace access
I see, Dror
Just in case, we are talking about 3.x version right?
So, you mean UserB is not a WorkspaceA's workspace/developer or admin is able to access files of private WorkspaceA's files with Project API calls correct?
On Tue, Mar 8, 2016 at 12:34 PM, Cohen, Dror <dror.cohen@xxxxxxx> wrote:
Hi Gennady,
No, I do not mean to assign them in an application scope.
Very Simply,
It seems that the "workspace\developer" role grants permission to user A to read/write in user B's
workspace.
I could not find any "ownership of workspace" check….
Is this by design?
How can I prevent write access to other user's workspace?
Regards,
Dror
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gennady Azarenkov
Sent: Tuesday, March 08, 2016 11:03 AM
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Question about Uses, Roles and Workspace access
If I understand you correct - You mean you assign those roles as for application scope?
I believe "workspace/admin", "workspace/developer" are not a global roles, they intended to be used in the context of particular workspace.
And so they are physically assigned for workspace member - i.e. "workspace member has a role of ..."
On Mon, Mar 7, 2016 at 4:59 PM, Cohen, Dror <dror.cohen@xxxxxxx> wrote:
Hi,
I would appreciate an explanation on Che Workspace permissions:
I am creating che users with the following roles:
"workspace/admin", "workspace/developer"
Currently,
User A can read and even modify a file in user B's workspace, even if I created the file in a
'visibility=private' project.
When debugging (in
che_core_vfs_impl) , I see that read or write permission is granted based on ACLs, on the user's
"workspace/developer" role,
even though that user is not a member of that workspace…
Could it be that this check is missing?
Or am I doing something wrong here…
I am trying to restrict a user's write access to another workspace.
I appreciate your help
Regards,
Dror
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
|
