Re: [SLUG] Sticky bit on /var/tmp
Quoting Joel Heenan : 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
Re: [SLUG] Sticky bit on /var/tmp
On Wed, Mar 10, 2010 at 10:07 AM, Craig Dibble wrote: > Does anyone have any thoughts on removing the sticky bit on the /var/tmp > directory and setting it to 777? 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. > 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. /var/tmp/ is for temporary files that survive between reboots[1]. If you have an application that requires lots of space, I would put it on a separate partition and keep it away from my OS partitions, maybe stuff it all somewhere under /opt/ [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE Joel -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Quoting Jake Anderson : Does anyone have any thoughts on removing the sticky bit on the /var/tmp directory and setting it to 777? Something about it doesn't sit quite right with me but I can't so far find any negative impact of doing so. Perhaps look at one of the more advanced access control setups, they extend the traditional unix user/group access and let you get fairly freeform. I thought about acls, setfacl might do what we want but I was after the simplest possible option. I might still have a look at this one. Alternately although not pretty could you not add your cleanup user to the group of the users? IE add cleanup to the frank group? That was the first thing I thought (well the second after sudo), but group perms won't make a difference on the directory with the sticky bit set. Thanks, Craig -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Craig Dibble wrote: Hi Hive Mind, Does anyone have any thoughts on removing the sticky bit on the /var/tmp directory and setting it to 777? Something about it doesn't sit quite right with me but I can't so far find any negative impact of doing so. 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. I'm fairly sure the first response to this will be "Use sudo", as that was our first response too, or "store the data somewhere else". Both of these are possible but difficult, the latter exceedingly so. We've tried to think of every sensible alternative but the simplest fix would be to just change the permissions and hope there isn't something which is going to bite us as a result. Any cautionary tales gratefully received. Cheers, Craig Perhaps look at one of the more advanced access control setups, they extend the traditional unix user/group access and let you get fairly freeform. Alternately although not pretty could you not add your cleanup user to the group of the users? IE add cleanup to the frank group? -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Quoting Daniel Pittman : 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. See, this is why I like tools like Condor, PBS, or the Sun Grid Engine. You get to let other people pay the big money to build features like cleaning up for you, so you don't have to. You get to play more golf.[1] Heh-heh. Unfortunately we're in full blown production, golf is not an option. Neither is replacing our systems. Might it be easier to provide a compatible API to users, and replace the inside with one of these tools? Not my call, but I can guarantee it's never going to happen, it is way too entrenched! 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? If you can do that, can't you just remove the files as root? Unless you are running on some strange platform that allows giving away file ownership to unprivileged users or something... Not quite as the cleanup process runs before the job exits. Anyway, it turns out this is not an option (my bad) as the pre and post hooks only operate at the farm process start/stop level, not on an individual job level. Hey-ho. Daniel Footnotes: [1] ...for some value of golf attractive to you, of course. ;) Our job is to make sure these things play nice in our environment. That can be a game in itself at times - with the commercial apps more so than the homegrown ones most of the time ;-) Thanks again, Craig -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Quoting Daniel Pittman : Craig Dibble 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
Re: [SLUG] Sticky bit on /var/tmp
Craig Dibble writes: > Quoting Peter Miller : >> 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? [...] > 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. See, this is why I like tools like Condor, PBS, or the Sun Grid Engine. You get to let other people pay the big money to build features like cleaning up for you, so you don't have to. You get to play more golf.[1] Might it be easier to provide a compatible API to users, and replace the inside with one of these tools? > 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? If you can do that, can't you just remove the files as root? Unless you are running on some strange platform that allows giving away file ownership to unprivileged users or something... Daniel Footnotes: [1] ...for some value of golf attractive to you, of course. ;) -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Craig Dibble 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? > 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. > 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. > > I'm fairly sure the first response to this will be "Use sudo", as that was > our first response too, or "store the data somewhere else". Both of these are > possible but difficult, the latter exceedingly so. We've tried to think of > every sensible alternative but the simplest fix would be to just change the > permissions and hope there isn't something which is going to bite us as a > result. ...er, is there any strong reason to run the cleanup script as some user other than root? Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Sticky bit on /var/tmp
Quoting Peter Miller : 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
Re: [SLUG] Sticky bit on /var/tmp
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. > 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. 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. 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. -- Peter Miller -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Sticky bit on /var/tmp
Hi Hive Mind, Does anyone have any thoughts on removing the sticky bit on the /var/tmp directory and setting it to 777? Something about it doesn't sit quite right with me but I can't so far find any negative impact of doing so. 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. I'm fairly sure the first response to this will be "Use sudo", as that was our first response too, or "store the data somewhere else". Both of these are possible but difficult, the latter exceedingly so. We've tried to think of every sensible alternative but the simplest fix would be to just change the permissions and hope there isn't something which is going to bite us as a result. Any cautionary tales gratefully received. 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
