Quoting Peter Miller <[email protected]>:
On Wed, 2010-03-10 at 10:07 +1100, Craig Dibble wrote:
Does anyone have any thoughts on removing the sticky bit on the
/var/tmp directory and setting it to 777?
Don't do it.
Yes, but why not? That's the bit I'm not sure about.
The sticky bit means a user can delete files in the directory if that
user owns the file they are deleting PLUS the owner of the directory can
delete files.
It's possibly worth saying that these are closed systems with no
interactive users, so we are not worried about users accidentally
deleting each others' files. My concern though is what other impact
might there be?
I would suggest using a rwxrwxrwt spool directory
in /var/spool/something owned by the uid that process the data.
Any user can spool data for processing, but only the app (and the user
who spooled the data) can remove the data files.
This is a possibility, but an exceedingly difficult one as any number
of homespun scripts, plugins and applications can be brought into
play, along with a large number of commercial applications, and they
would all need to be told to write to the spool directory. Nice idea
though, and you have given me another idea - maybe just making the
control process the owner of /var/tmp would solve the problem?
If you're curious, this is a large render farm controlled by a
homegrown job scheduler, the users submit jobs and the scheduler takes
over - hence our current problem. We have pre and post hooks available
though, so maybe doing a chmod or chown on the directory at the start
and end of every job would suffice to keep everyone happy?
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
