In the new version of Easymorph server, there is a new authorization needed to read connectors from server and modify it. So you may think that when you have the read only authorization you can not get the connector content but actually … you still can. Why ?
Because the repo.sqlite of one space must have the read rights for service account. And because the tasks are launched by the service account. So today one user can create a task listing all the files accessed by service account and their content. It means he can read the encrypted passwords inside repo.sqlite and use it in easymorph which is a security break. Generally speaking, it’s a real problem that a task is launched by service account, with service account rights, particularly on file system access.
How can this be secured ? Do you have any idea ?
I just checked it again - it’s not possible to get the connector content when the space repository is set to read-only. Make sure you reloaded your connectors in Desktop after space settings changed. Or restart application.
If you want to prohibit low-level file operations such as accessing files outside of the Public folder, disable arbitrary code execution in space settings.
Making Server repository files physically unusable on Desktops is a good question - something to think about.
We’re aware of the problem of tasks sharing the same account. EasyMorph Server was initially designed to work in a trusted environment in a department. The more it evolves towards an enterprise system the more it is expected to accommodate enterprise-level security practices.
Not sure I understand corretly the answer but I confirm that if I create a project that reads the repo.sqlite of the space (which is in the repository folder, outside the public folder space of course) and if I execute it as a task on the server, the project will be successfull, even though arbitrary code execution is disabled.
If you tell me that arbitrary execution code prevents from reading files outside of public folder, I think it does not work : I can read the files inside the repository folder of the space.
Preventing arbitrary code execution doesn’t affect what files can be read.
We will add repository encryption to make sure that a repository can’t be reused without authorization.
I like the idea of not being able to manipulate files outside the public folder of the space, not having any access to them (read/write). But I don’t know if it’s technically possible.