Hello,
We are looking to build a CryoSPARC installation on a campus-wide SLURM GPU server. Since this installation will potentially span multiple labs, I was hoping for some clarification on how cryosparc handles read/write permissions at the user level.
I know that the master process is run by a central linux user (we will call “cryosparc-admin”, which will need read/write access to any/all project directories), and access to the filesystem is done under the “mask” of this user account. In this way, if we have users from two different labs (can call them “user1” from “lab1” and “user2” from “lab2”), then they could potentially gain access to each other’s directory trees through this central “cryosparc-admin” linux user.
Is there some way to limit the permissions of independent users? Such that “user1” can only see and create projects under /data/cryosparc_projects/lab1 and “user2” can only do the same under /data/cryosparc_projects/lab2, or will “user2” always be able to see /data/cryosparc_projects/lab1 (and vice versa)?
Thanks in advance.
Hi @sbowerma,
We have just added a section to the CryoSPARC guide which covers how to achieve some degree of data separation between user groups. Here’s a link to it: https://guide.cryosparc.com/setup-configuration-and-management/management-and-monitoring/unix-permissions-and-data-access-control
In summary, though, you are correct that the cryosparc-admin user will have access to all data on the instance. By working with unix permissions it’s possible to limit shell-based access to other group’s data, and you can limit which users can see a given cryoSPARC project from within the UI (which does establish some degree of separation), but since the cryosparc user can see all the files, one group could create an import movies job, for example, and import data that’s supposed to be owned by another group.
We do plan to eventually address this in a future release but I can’t comment on the exact timeline. In the meantime, depending on how tight your security requirements are, the strategy in the linked guide section may suit your needs.
Another possibility would be to have multiple cryoSPARC instances, each with their own unix account, database, etc. We don’t normally recommend that kind of setup because it tends to introduce other problems (for example, the two instances won’t be aware of which GPUs are currently in use by the other instance), but using SLURM does mitigate those issues to a degree.
–Harris
1 Like
Hi CryoSPARC,
Are there any new updates on tightening up access for multi-users scenario?
I was thinking if we can manually turn off the features for CryoSPARC user accounts to import data that may be owned by another group, and only cryosparc admin account can import data for different groups’ projects in cryosparc, this concern may be worked around a bit. ref. https://discuss.cryosparc.com/t/feature-request-an-environment-variable-to-disable-enable-import-jobs-for-certain-users/13031/4
Regards,
qitsweauca
@qitsweauca We do not have additional updates regarding multi-user instances, but we have noted the request.
For this particular scenario, I would suggest hosting separate CryoSPARC instances for each group, and running each instance on a distinct Linux account.
You may host multiple CryoSPARC instances on the same host as the instances’
- port ranges do not overlap
- databases are separate
- license IDs are unique
- combined interactive workloads can be handled by the server
1 Like
@wtempel Thanks for your reply. : )
The feature request was essentially stemmed from a scenario where CryoSPARC instance is installed in a HPC environment with a big shared storage space for a multi-user use case. So to avoid a normal cryosparc/hpc user to access other users’ data and raw data and import them, I find it one of the best ways is to disable users’ import functionality and only facility or admin cryosparc user can do the importing for normal users. Although it may seem a bit tedious still, I reckon it might be one of the effective ways to tighten the access without having the long way to implement account integrations (e.g. OpenID, LDAP etc) with system accounts…
But, yes, thanks for your update. Thank the CryoSPARC team and the on-going great, awesome capabilities. Look forward to more future updates.
Cheers,
qitsweauca