BUG - Opening apps opened other users jupyterlab servers for me

[Adam-D-Lewis]

Context

I opened the xaitkappv3-d7dff58 app by @kcpevey and the maite-c383ebc by @dharhas and instead of opening the apps, a jupyterlab server was created as if I were kim and dharhas's users. Afterwards, I checked the jhub-apps home page again and the xaitkappv3-d7dff58 and maite-c383ebc apps weren't listed anymore.

Maybe they were deleted, but still shown on jhub-apps home page and when I tried to open them jupyterhub forwarded me to jupyterlab? I'm not sure.

Me as Kim in jupyterhub

Me as Dharhas in jupyterhub

Value and/or benefit

Bug report

Anything else?

No response

[dharhas]

The way this works is by impersonating their user, so that part is not surprising. During the lead up to the release we did have weird routing issues where it would start lab instead of redirecting to the url of the 'app'. I don't remember exactly but this was some combination of the version of jupyterhub, jupyterlab and jhsingle-user-proxy that was causing the issue. I thought it was fixed in the release.

cc: @aktech

[aktech]

weird routing issues where it would start lab instead of redirecting to the url of the 'app'.

This might be the case, will have to check app's creation commands to figure out what went wrong. I'll take a look.

[kcpevey]

I just hit this too. My situation:

• Dharhas had a shared app that had been stopped.
• I started the app (which led me to confirm I wanted to launch a server)
• I waited for the server to spin up
• When the server was up, it redirected me to Dharhas's JLab interface - I was impersonating him.
• I went back to the app screen and clicked on the App link and it brought me back to Dharhas's Jlab.

We need to disable the ability to have general jupyterlab access and restrict to just the app. There may be some fine grained permissions in JHub/JLab that will allow this now.

[krassowski]

This may be tangential but if user A starts a shared app of user B, but user A only is allowed to spawn say CPU instances, but user B is allowed both CPU and GPU, should user A be allowed to spawn the GPU instance as user B or not? Currently user A can spawn instances that they would have no access to if they were spawning their own app rather than a shared one.

Edit to clarify:

Instances I have access to when spawning as myself	Instances I have access to when spawning as Amit

[aktech]

IMO the user A ideally should be able to spinup the shared app with only the last saved configuration for the app. They should not be able to change a thing about it like server type, name, thumbnail etc.

Also note that, currently the starting of the shared app won't work as expected due the "fake" sharing ability we have: #138

[krassowski]

Interestingly the problematic apps disappear from shared apps screen when a server for them gets spawned

before spawning "My panel app"	after

But now that you linked #138, it seems to mention the same thing, right?

[krassowski]

Taking a step back:

• solving [BUG] Stop ability of starting stopped shared apps from JupyterHub interface #138 would "solve" this issue in the sense of surprising behaviour for end-user, but would not solve the impersonation itself nor too broad permission scopes
• we can configure "Real-time collaboration without impersonation": https://jupyterhub.readthedocs.io/en/stable/tutorial/collaboration-users.html - which we could start already
• to only allow access to servers which are actually shared by the author we should use sharing codes https://jupyterhub.readthedocs.io/en/latest/tutorial/sharing.html which are coming in JupyterHub 5.0

How should we scope the work here? It looks like these are 3 tasks which all are critical to ensuring that user data is only shared when explicitly allowed and no impersonation takes place - do I see this right?

[krassowski]

Just coming back to this issue @aktech did you have a chance to look into this?

[aktech]

solving #138 would "solve" this issue in the sense of surprising behaviour for end-user, but would not solve the impersonation itself nor too broad permission scopes

Yes, correct.

we can configure "Real-time collaboration without impersonation": jupyterhub.readthedocs.io/en/stable/tutorial/collaboration-users.html - which we could start already

Yes we can, but this is beyond the scope for app sharing requirements.

to only allow access to servers which are actually shared by the author we should use sharing codes jupyterhub.readthedocs.io/en/latest/tutorial/sharing.html which are coming in JupyterHub 5.0

Sharing code is also a good option for sharing temporarily (excellent feature to add later though), but initially we are more interested in sharing non-timebound access with a group or user via: https://jupyterhub.readthedocs.io/en/latest/reference/rest-api.html#operation/post-shares-server

Based on my reading of the sharing feature in JupyterHub 5.0, we will fix this issue after:

• We implement app sharing using sharing APIs in 5.0: https://jupyterhub.readthedocs.io/en/latest/reference/rest-api.html and
• fixing [BUG] Stop ability of starting stopped shared apps from JupyterHub interface #138, this will also be solved when we stop showing all the apps to all the users (at the moment we show all the apps for all the users in the shared section)

Next steps:

• I am working on writing an issue for implementing app sharing via 5.0, shall have it today.
• Stop showing all the apps to everyone, remove this basically

  jhub-apps/jhub_apps/service/routes.py

  Lines 140 to 142 in 6a5df08

  	"shared_apps": get_all_shared_servers(
  	hub_users=users, current_hub_user=current_hub_user
  	),

Also, there is nothing that needs to be done to fix this one right now, as mentioned it will be fixed by implementing app sharing.