- marked as enhancement
access rights in the cache directory
The mss UI saves the figure data in the cache directory, e.g. /tmp/.cache/.mss/msui/ On first use this directory is created If more than one person is using this on the same system, this does create access probelms. The second user is not allowed to write to the same directory.
This was even the case if the cache box was unticked. It should be ensured that there will be no conflict, either by generally setting write permissions to this directory or by creating individual cache directories.
Comments (11)
-
reporter -
reporter Since the cache dir can be defined in the file mss_settings.json this problem could be avoided. However, an intelligent way needs to be found to define better the default cache directory.
-
Hi, according to the XDG specification https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#basics the location of the cache directory should be read from XDG_CACHE_HOME. and should use $HOME/.cache/ if not set. In any case, we should at least use a user-specific directory to avoid such problems in the default installation in the future.
-
-
We have set a default but any user can overwrite it in his configurations, If we change that default, we need a path which on all circumstances works again. The current behaviour is documented as default: https://mss.readthedocs.io/en/stable/usage.html
This problem usually occures if someone else installs the software and a new user did not read anything. This is a common path on e.g. debian packages.
A better solution may be that we have on first call of mss a configuration done by the user, where he has to answer some questions and gets by that the config updated. As we have json as config, we should look for some flatland like qt interface that generates a form from an existing configuration.
We may be also want different kind of installations and configs described. The installation one for all isn't described yet.
-
Okay, I looked into our code and while not XDG compliant, I think our chosen path is safe and sound:
wms_cache = os.path.join(tempfile.gettempdir(), "msui_wms_cache")
which is a unique temporary directory. Is the issue related to a "misconfiguration", i.e. was the same cache directory configured for all seats? I was under the impressions that we had a bug here. A joint directory should not work, simply for security reasons. So I am confused, how to proceed here.
-
reporter Yes, I think, the issue is related to this kind of configuration. The default configuration was used on a shared user system and I didn't realize, that the path to the cache die was in the settings file.
Is is possible to check if the user owns the cache dir, and if not, terminate with an error message, that the path needs to be adapted?
-
@grooss if we won't set a config var for that case than it had worked out of the box. At the moment we don't have a config file checker, besides that we expect valid json.
It may be a nice feature to verify some essential parts on each startup of mss. e.g. data_dir, wms_cache
-
documnentation could be also improved, adding a snippet for changes
-
- changed status to resolved
examples from the documentation for caching changed, fixes
#375→ <<cset f391d1a1bef8>>
-
Merged in ReimarBauer/mss/i375 (pull request #592)
examples from the documentation for caching changed, fixes
#375→ <<cset 5419257a73c6>>
- Log in to comment