review and potentially modify /var/tmp/$USER for session data

[johrstrom]

#2806 reminded us that maybe /var/tmp/$USER is not an appropriate location for session data in the dashboard.

The initializer in question is here:

https://github.com/OSC/ondemand/blob/e812e7d9b56a122fd6efdecfb84efd17fd91303a/apps/dashboard/config/initializers/session_store.rb#L5

It makes this directory and uses it to store the dashboard's session data. With systemd cleaning this directory over time, it may not be the best place for this as this data could get clean up out from under us.

┆Issue is synchronized with this Asana task by Unito

[johrstrom]

Circling back to this now @treydock - do you think we need to do anything here?

I'm also wondering if we should have age arguments to the file below. I know for sure the directory/files in this ticket are valid while they're in use and if they're wiped while still in use there could be issues.

I'd have to check on the files in the other locations - but I do worry what the behavior is if they're wiped while they're still in use.

https://github.com/OSC/ondemand/blob/master/packaging/files/ondemand-nginx-tmpfiles

[treydock]

I think this might be a documentation change. I'm fairly certain, though not 100%, that when we omit the age parameters from our tmpfiles the defaults from OS files are used:

[tdockendorf@webdev02 ~]$ cat /usr/lib/tmpfiles.d/tmp.conf
<SNIP>
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
<SNIP>

I'm fairly certain the behavior will ignore things with like mtime or atime newer than 30 days so I can't imagine this is deleting things in use.

The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for
       directories) its last status change timestamp (ctime). Any of these three (or two) values will prevent cleanup if it is more recent than the current time
       minus the age field.

That's from man tmpfiles.d