in our setup multiple users work on a single instance of Cryosparc. The users are not supposed to see the data from each other (unless the project is explicitly shared). This works well in the web interface, however, there is an issue with the cluster file system. The cryosparc instance is run by the admin user, who can see all of the data, whereas the users can only see the data based on their Unix group.
In the file selection dialog a user can browse to any folder on the file system and thus can bypass the access restrictions enforced by the Unix groups, because the file selection is done by the admin user. For instance, I can navigate out of my project folder to a different project folder and import cryosparc result groups, such as maps or micrographs.
I think a possible solution would be to modify the file selection dialog in such away that it cannot go anywhere outside the project folder. This way the user has to have access to the project folder in the file system in order to import data into cryosparc. A similar approach is for instance used by ipyfilechooser widget (see option sandbox_path)
Do you think such functionality can be added to future releases? Or any other suggestions on how to prevent unauthorized access?
A CryoSPARC instance should only be shared between users who trust each other and when the shared visibility of data would not be a concern. If this visibility would be a concern, one may want to host multiple CryoSPARC instances (possibly under separate Linux accounts) such that no users who should not see each other’s data would be sharing the same instance and data visibility can be restricted at the OS level.
One may host multiple CryoSPARC instances on the same host if each instance has a unique
Thanks for the clarification! Indeed, we are not using root to run the master node, but rather a user with additional privileges.
While your proposed solution does indeed solve the issue - I think this is how many university HPC’s set this up - it does not scale well. Cryosparc master requires plenty of resources to run, and I imagine that maintaining over 5 separate installations will get cumbersome. In our case we are looking towards 15 or more installations, one for each project run by a group of users.
I also realized that my proposed fix about limiting the scope of the filesystem is unlikely to solve the issue. For instance, a user could see full folder paths in the SLURM queue, symlink the folders into their project folder and then import other people’s results via the cryosparc web UI.
I guess the real solution where one gets a single master installation and proper file access permissions is to map Unix users to cryosparc users and then execute jobs in the Unix user’s name.