name collision on multiuser system (Trac #1078)

[pkienzle]

On a linux system the compiled models are placed in /tmp/MODELNAME.so. If one user creates a model and another user updates it, there will be a permission collision.

Also, what happens to the .so if the plugin model has the same name as a builtin model?

Migrated from http://trac.sasview.org/ticket/1078

{
    "status": "new",
    "changetime": "2018-03-05T23:43:57",
    "_ts": "2018-03-05 23:43:57.723729+00:00",
    "description": "On a linux system the compiled models are placed in `/tmp/MODELNAME.so`.  If one user creates a model and another user updates it, there will be a permission collision.\n\nAlso, what happens to the .so if the plugin model has the same name as a builtin model?",
    "reporter": "pkienzle",
    "cc": "",
    "resolution": "",
    "workpackage": "SasView Bug Fixing",
    "time": "2018-03-05T23:40:20",
    "component": "sasmodels",
    "summary": "name collision on multiuser system",
    "priority": "major",
    "keywords": "",
    "milestone": "sasmodels 1.0",
    "owner": "",
    "type": "defect"
}

[pkienzle]

Trac update at 2018/03/05 23:43:57: pkienzle commented:

For now put compiled models in ~/.sasmdoels/compiled_models like happens in windows.

Consider other locations.

And still, consider the problem of plugin name collision.

[pkienzle]

sasmodels uses a number of environment variables to control file locations. Check that the defaults are sensible. https://github.com/SasView/sasmodels/blob/9fac5f5b2fd6a440d3b4df58c692047b489d5ba3/sasmodels/compare.py#L116

dlls are in SAS_DLL_PATH: https://github.com/SasView/sasmodels/blob/9fac5f5b2fd6a440d3b4df58c692047b489d5ba3/sasmodels/kerneldll.py#L109

opencl cache is in XDG_CACHE_HOME (linux only): https://github.com/SasView/sasmodels/blob/9fac5f5b2fd6a440d3b4df58c692047b489d5ba3/sasmodels/compare.py#L119

Don't know where pycuda caches its files, but it is the same author as pyopencl, so probably a similar location.

[pkienzle]

Adding md5 sum to the file name changes the problem a bit (#212, #218). Then a hostile user can put a corrupted .so file in the public space which matches the hash of another users model. Next time that user runs the model the corrupted code is run. So, put models in private space and have each user compile their own.

[RichardHeenan]

Could each sasview session create its own sub-directory for compiled models, then delete it when the session ends? - thus not clogging up our hard drives for ever more with old compiled code.

I have several times had issues on WIndows (OK messing around with developer stuff) when I have had to delete all the .so, but even then have had one locked by another sasview session; also had to do likewise when hopping between 32 & 64 bit versions.