Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RStudio/rsession is not launched when using LDAP and container-volumes mapping #9

Open
thien-bui-coherent opened this issue Oct 23, 2024 · 2 comments
Labels
question Further information is requested

Comments

@thien-bui-coherent
Copy link

I've been running this example successfully since ShinyProxy 2.6.0 with LDAP authentication (Microsoft Active Directory) and container-volumes mapping. It is also working fine with ShinyProxy 3.0.1. However, after I upgraded to ShinyProxy 3.1.0 and 3.1.1, this example failed to work. ShinyProxy can still authenticate with LDAP and spin up the RStudio-ide container but the new web page is blank. I can 'docker exec -it ... bash' into the RStudio-ide container and verify that DISABLE_AUTH=true, USER=proxyUserId from LDAP, WWW_ROOT_PATH=proxy.getRuntimeValue('SHINYPROXY_PUBLIC_PATH'). rserver process is up and running by rstudio-server, but there is no process for rsession.
For the same ShinyProxy configuration, the RStudio-ide example is working with ShinyProxy 2.6.0 and 3.0.1 and LDAP authentication. With ShinyProxy 3.1.0/3.1.1, I found that this example only works with LDAP authentication when there is no container-volumes mapping. When there is container-volumes mapping, it only works when ShinyProxy authentication mode is none or simple. My guess is there some new security check in ShinyProxy 3.1.0/3.1.1 that prevents the rserver process in the RStudio-ide container from launching an rsession process to serve the LDAP-authenticated user in the mapped volume.

@thien-bui-coherent thien-bui-coherent changed the title RStudio/rsession is not launched when using LDAP RStudio/rsession is not launched when using LDAP and container-volumes mapping Oct 23, 2024
@LEDfan LEDfan added the question Further information is requested label Oct 28, 2024
@LEDfan
Copy link
Member

LEDfan commented Oct 28, 2024

Hi, I cannot reproduce the problem in the way you describe.
For me volume mounts work fine, also when using LDAP. It's important that the volume is owned by uid 1000, especially when it's mounted as /home/rstudio. Otherwise the rstudio user inside the container, will not have access to it and startup of rstudio fails.

So for example, if you mount it like

    container-volumes: [ "/tmp/#{proxy.userId}:/home/rstudio" ]

and you login as jack, you must make sure /tmp/jack is owned by uid 1000.

@thien-bui-coherent
Copy link
Author

I actually use this mapping:
container-volumes: ["/remote/home/#{proxy.userId}/rstudiowork:/home/#{proxy.UserId}"]
The uid of proxy.userId is from LDAP and definitely not 1000.
This mapping works fine with ShinyProxy 2.6.0 and 3.0.2. It fails with 3.1.0 and 3.1.1.
Is there a way to disable this security enhancement in 3.1.x?
Is there a way to obtain the uid and gid from LDAP, i.e. #{proxy.UserUId}, #{proxy.UserGId}? so that I can pass them into the RStudio container and have it creating the user's account with matching uid/gid?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants