Quoting Daniel Pittman <dan...@rimspace.net>:
Craig Dibble <cr...@rootdev.com> writes:
Does anyone have any thoughts on removing the sticky bit on the /var/tmp
directory and setting it to 777?
Why would you want to allow unprivileged user to delete temporary files
created by other unprivileged users?
For the reasons given below. If it was just a case of letting tmpwatch
take care of it it wouldn't be a problem, but the amount of data churn
is just too high.
Something about it doesn't sit quite right with me but I can't so far find
any negative impact of doing so.
Other than the marginally increased, and probably mostly theoretical in these
days of one-user-per-machine, security risk there isn't much.
That's good to know. Like I said, they're closed systems and already
locked down so if that's all there is to it we could live with 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. We have cleanup scripts which
need to be able to remove files and folders to reclaim space every time a
job finishes but the files are created by the user who launched the job, and
the control process, and hence the cleanup, runs as a different user. And
there we have a problem as the sticky bit prevents the cleanup from running
and we have boxes falling over because their disks fill up.
...er, is there any strong reason to run the cleanup script as some
user other
than root?
Only that it isn't really a cleanup script per-se, it's a process that
runs deep in the job scheduler code - hence the fact that our original
and perfectly
sensible suggestion of sudo would have been very painful to implement.
At the moment it looks like the least painful option is simply to make
the job scheduler the owner of /var/tmp.
Thanks for your insight.
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
