[rt-users] Re: rt-users Digest, Vol 4, Issue 31

[Rick Ellis]

I have also seen this issue and not yet been able to find a clean RT
based answer. Experimenting with permissions on one of our isolated
boxes, RT still doesn't seem to clean up properly.

I now use a Linux trick on our Solaris box to effectively run tmpwatch
via crontab and delete any of these directories that are over 10 days
old.

It seems to work well until a better solutions comes along.

Rik
On Wed, 2004-02-11 at 07:17, rt-users-request at lists.bestpractical.com
wrote:
> Message: 4
> Date: Wed, 11 Feb 2004 02:20:12 -0500
> From: "AJ" <rt at musefoundry.com>
> Subject: RE: [rt-users] Directories left in /tmp
> To: "'Patrick LeBoutillier'" <patl at fusemail.com>,
> 	<rt-users at lists.bestpractical.com>
> Message-ID:
> 	<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAA9tUWdOmOUE+6g2RIHUkSNAEAwYmj7r9QD0mtN+MAvAz3KwAAABnaGwAAEAAAAOE3Fw3VjVpNsf3weXoaXj4BAAAAAA==@musefoundry.com>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> I submitted a bug report about this a couple weeks ago.  However, looks like
> this may be a universal thing, I figured it was a FastCGI thing...
> 
> This is what I managed to dig up.
> 
> RT uses CGI and File::Temp.  For CGI, the -private_tempfiles is used.  
> 
> Now CGI puts its temporary files in /var/tmp and File::Temp places its files
> in /tmp.  However I think there may be some kind of conflict between the
> two.  I conducted a little experiment and pulled the -private_tempfiles out
> of the code and saw that /var/tmp was not cleaned (CGI was leaving the
> attachments in there) but the two directories and one file created per
> attachment handled by File::Temp was cleaned out.
> 
> The CGI manpage says: CGI.pm can process uploaded file. Ordinarily it spools
> the uploaded file to a temporary directory, then deletes the file when done.
> However, this opens the risk of eavesdropping as described in the file
> upload section. Another CGI script author could peek at this data during the
> upload, even if it is confidential information. On Unix systems, the
> -private_tempfiles pragma will cause the temporary file to be unlinked as
> soon as it is opened and before any data is written into it, reducing, but
> not eliminating the risk of eavesdropping (there is still a potential race
> condition). To make life harder for the attacker, the program chooses
> tempfile names by calculating a 32 bit checksum of the incoming HTTP
> headers.
> 
> Removing the private files flag from CGI will not cause the temporary files
> to be unlinked as soon as they are opened. Perhaps CGI is unlinking the file
> before File::Temp has a chance to delete the files through its cleanup
> mechanisms?  Also, with File::Temp, the CLEANUP=>1 is used.  What this does
> is instruct File::Temp to delete the directory in which it put the temp
> files.  Since its using tmp, and the user that the web server is running
> under probably doesn't have the permissions needed to remove tmp, could
> File::Temp just be giving up and leaving them there?  I have no clue.  I
> started looking at it but this is beyond my level of programming skill and I
> don't have the time to figure it out.   
> 
> In the meantime, I just created a cron job that goes in and deletes the tmp
> files and directories from time to time.
> 
> Perhaps someone may be better suited to figuring this one out....
> 
> A.J.
> 
> -----Original Message-----
> From: rt-users-bounces at lists.bestpractical.com
> [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Patrick
> LeBoutillier
> Sent: Tuesday, February 10, 2004 11:48 AM
> To: rt-users at lists.bestpractical.com
> Subject: RE: [rt-users] Directories left in /tmp
> 
> I have the same problem. It looks like they are web session directories,
> but I thought RT sotred the web session data in the database...
> 
> Patrick
> 
> On Mon, 2004-02-09 at 13:30, Adolfo Santiago wrote:
> > On my system they are owned by the web user and group (httpd.httpd), so I
> > suspect they are created by it, maybe when mail is sent out?
> > 
> > Chago
> > 
> > 
> > > -----Original Message-----
> > > From: rt-users-bounces at lists.bestpractical.com
> > > [mailto:rt-users-bounces at lists.bestpractical.com]On Behalf Of Mick Szucs
> > > Sent: Monday, February 09, 2004 1:19 PM
> > > To: rt-users at lists.bestpractical.com
> > > Subject: [rt-users] Directories left in /tmp
> > >
> > >
> > > Hi all,
> > >
> > > I've seen this question raised a few times but haven't yet seen a
> > > response so
> > > I thought I'd re-ask it.
> > >
> > > On my RT3 system I'm seeing hundreds of directories left in /tmp like:
> > >
> > > /tmp/scwMaa3T5Y
> > > /tmp/OeNgSLNygq
> > >
> > > some of them contain files that indicate these are residue from some
> MIME
> > > decoding that's happening.
> > >
> > > Does anyone know where they come from or whether or not they can
> > > be eliminated
> > > (95% of them are empty.)
> > >
> > > Thanks,
> > > --
> > > Mick Szucs  <mick at onramp.ca>
> > > Onramp Network Services Inc.
> > >
> > > _______________________________________________
> > > rt-users mailing list
> > > rt-users at lists.bestpractical.com
> > > http://lists.bestpractical.com/mailman/listinfo/rt-users
> > >
> > > Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
> > >
> > >  ** CRM114 Whitelisted by: lists.bestpractical.com **
> > >
> > 
> > 
> > _______________________________________________
> > rt-users mailing list
> > rt-users at lists.bestpractical.com
> > http://lists.bestpractical.com/mailman/listinfo/rt-users
> > 
> > Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
> 
> _______________________________________________
> rt-users mailing list
> rt-users at lists.bestpractical.com
> http://lists.bestpractical.com/mailman/listinfo/rt-users
> 
> Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

-- 
Rick Ellis <Richard.Ellis at Sun.COM>