Quoting Joel Heenan <[email protected]>:
In the past there have been exploits which relied upon racing
processes then modify files they have placed in /tmp or /var/tmp to
gain elevated privileges. Googling "race tmp exploit" will show up
lots of these. It is almost certainly bad practice to do this.
Hi Joel,
Given that these systems will only ever process one job at a time and
have no interactive users that's not really a concern, but even so it
still didn't sit comfortably with me, I just couldn't put my finger on
why not so thanks for that.
The reason for this is that we have a large amount of data moving through
that folder, in the order of more than 100GB.
I think data of that size belongs in /var/cache/ or /var/spool/ or
simply somewhere else entirely.
We don't particularly like the fact that the data is there. It's all
scratch or cache data, some of which we want to persist for given
periods of time, some we don't care about or want gone as soon as the
current job finishes. It gets written by a variety of apps, and moving
it elsewhere, though the best solution, simply isn't going to happen
in the short term.
In the end I left the permissions the way they were and made the job
scheduler the owner of the directory.
Cheers,
Craig
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
