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.
RikOn Wed, 2004-02-11 at 07:17, rt-users-request@lists.bestpractical.com wrote:
Message: 4
Date: Wed, 11 Feb 2004 02:20:12 -0500
From: “AJ” rt@musefoundry.com
Subject: RE: [rt-users] Directories left in /tmp
To: “‘Patrick LeBoutillier’” patl@fusemail.com,
rt-users@lists.bestpractical.com
Message-ID:
!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAA9tUWdOmOUE+6g2RIHUkSNAEAwYmj7r9QD0mtN+MAvAz3KwAAABnaGwAAEAAAAOE3Fw3VjVpNsf3weXoaXj4BAAAAAA==@musefoundry.comContent-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@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Patrick
LeBoutillier
Sent: Tuesday, February 10, 2004 11:48 AM
To: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Directories left in /tmpI 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@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of Mick Szucs
Sent: Monday, February 09, 2004 1:19 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Directories left in /tmpHi 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/OeNgSLNygqsome 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@onramp.ca
Onramp Network Services Inc.
rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users ArchivesHave 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@lists.bestpractical.com
The rt-users ArchivesHave you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users ArchivesHave you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
Rick Ellis Richard.Ellis@Sun.COM