I was wondering if there is an easy solution for dropbox scripts to check or limit access to the import targets. Dropbox scripts do not use authentication, but import datasets to the specified targets regardless of roles and permissions. If we use the standard or indiviual generic dropbox script, everybody with the right to write to the import folder can import datasets, even to protected spaces of other users. This way a user can accidentally (or intentionally) flood foreign folder structures with data sets.
I’m thinking about a property (allow_dropbox) for collections or objects, that could be checked by the script. Or even a property with a ‘secret’, that has to match informatuion provided by the import-data.
Any ideas on this?
Users can indeed drop any data to the dropbox, this has always been a compromise with drawbacks as the one you have pointed out.
Let’s explore possibilities:
Personal Dropboxes: Ideally users only have access to dropboxes that can ingest data on spaces they have access, so you could say that potentially every user needs to have his own dropbox that makes use of the user rights. This is perfectly doable with little effort but becomes an administrative nightmare for the admins to guarantee that users can only mount their dropbox.
Dropbox checking the future owner of the dataset for allow/disallow logic as you point out. This can also be an administrative nightmare since every users needs to remember to allow or disallow into their collections and objects.
Dropbox with additional blacklist of spaces: So they can be configured more broadly by admins.
Local landing zones in the users computer that make use of the user rights: This is a new mechanism that we hope to introduce mid-life of the next openBIS mayor version with the new DSS. It has all the advantages of personal dropboxes without the administrative nightmare.
For me only 4 seems to be better long term to minimise administration, but is also true is probably a good year or year and a half away.
So the question would be, if we implement 3 on the general eln-lims dropbox to blacklist special spaces, would it be enough short term?
Please feel free to counter argument my points, or expand upon them, I’m just thinking loud.
a short term solution with blacklists would be nice. Would the lists be managed by the system administrator or an instance admin or in a different way?
Local landing zones at the clients (solution 4) may not work in all cases. At the moment we have special lab networks without direct access to the openbis servers. The only way to import data is to write to dropbox folders on file shares which are also mounted on the servers (smb). The shares are usually accessible by a whole group of users. In this scenario we may need something like solution 2.