LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 10-23-2009, 05:58 PM   #16
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530

Quote:
Originally Posted by r3sistance View Post
I have seen a number of rootkitted machines with scripts in /tmp....
Since /tmp is writable for all the scripts you see most likely are just collateral, not the actual compromise. And while dropping for instance a Perl backdoor script in /tmp the "noexec" mount flag would prohibit one from executing the script directly, calling it from the web application or prefixing the interpreter in the CLI one could still run it. Also please be mindful taxonomy-wise calling something a root compromise or a machine as "rootkitted". I mean a LAMP stack compromise may result in a root compromise but it does not have to. Probbly superfluous to say but more than half of securing /tmp means preventing events from taking place by not disabling SELinux or GRSecurity, by properly hardening the machine, regularly auditing it, actually reading reports and adjusting the configuration.

* OTOH if you have access to or reports of rootkitted machines then I'm always interested in hearing about those in the Linux Security forum.
 
Old 10-23-2009, 06:03 PM   #17
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
Quote:
Originally Posted by mejohnsn View Post
But why is this procedure better than using 'tmpwatch' in a cron job??
Whatever gave you the impression it would be "better" in any way?
Tmpwatch has checks built in to avoid race conditions and stuff.
This kludge has not.
YMMV(VM).
 
Old 10-24-2009, 04:24 AM   #18
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Quote:
Originally Posted by unSpawn View Post
Whatever gave you the impression it would be "better" in any way?
Tmpwatch has checks built in to avoid race conditions and stuff.
This kludge has not.
YMMV(VM).
Hi UnSpawn. What makes you call it a kludge?
 
Old 10-24-2009, 06:16 AM   #19
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
As in "does it's job without giving thought to other aspects"? Also see: a hack, a workaround, cobbling up something.
 
Old 10-24-2009, 09:48 AM   #20
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Quote:
Originally Posted by unSpawn View Post
As in "does it's job without giving thought to other aspects"? Also see: a hack, a workaround, cobbling up something.
Thanks That's a good explanation of what "kludge" means but which "other aspects" do you have in mind? The technique is used immediately after /tmp has been mounted (or immediately after it has be re-mounted rw) so nothing new has been written to /tmp. The only files-and-directories under /tmp are ones from before shutdown ...
 
Old 10-24-2009, 10:11 AM   #21
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
Quote:
Originally Posted by catkin View Post
which "other aspects" do you have in mind?
I'll mention configurability and security but since I mentioned 'tmpwatch' maybe you could spare 1 minute and look at its features?


Quote:
Originally Posted by catkin View Post
nothing new has been written to /tmp. The only files-and-directories under /tmp are ones from before shutdown ...
I wonder if that is an assumption or an observation? If it is an observation does it apply to only that specific machine or to a range of machines possibly with different purposes and reboot schemes? And how would this behave if there are files that should not be removed on reboot? Say collateral from a breach of security? And to a (way) lesser extent, how about the time it requires to recreate default files and directories created at boot for use by subsystems?
 
Old 10-24-2009, 11:25 AM   #22
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Quote:
Originally Posted by unSpawn View Post
I'll mention configurability and security but since I mentioned 'tmpwatch' maybe you could spare 1 minute and look at its features?
Thanks, I'd already done that; it looks useful and thorough but I still prefer a "good enough" solution that does not require an extra package -- as long as it is "good enough", which concern is my reason for asking these questions.

Quote:
Originally Posted by unSpawn View Post
I wonder if that is an assumption or an observation? If it is an observation does it apply to only that specific machine or to a range of machines possibly with different purposes and reboot schemes? And how would this behave if there are files that should not be removed on reboot? Say collateral from a breach of security? And to a (way) lesser extent, how about the time it requires to recreate default files and directories created at boot for use by subsystems?
It's an assumption but seems like a reasonable assumption -- unless there are any processes already running, waiting for /tmp to become writeable when they will write to it.

Good point regards observation; I've added a line in rc.S to show what is there but, as you point out, this can only ever yield system-specific data from which it is impossible to generalise with certainty.

Regards "files that should not be removed on reboot" I am in the happy position of having a system on which it is OK for things to break if such files are removed, on which it is OK to experiment.

I do not know enough about files "collateral from a breach of security" except to think out loud that rebooting a possibly-compromised system could destroy a lot of evidence besides files-and-directories in /tmp; if it has to be shut down (as opposed to disconnected from the network) then wouldn't a serious investigation require disk imaging before any reboot?
 
Old 10-24-2009, 12:48 PM   #23
mejohnsn
Member
 
Registered: Sep 2009
Posts: 174

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by arizonagroovejet View Post
If it's in /tmp and you reboot you shouldn't expect it to be there. So you can delete the contents early in the boot process or late in the shutdown process.

SUSE distros have a setting CLEAR_TMP_DIRS_AT_BOOTUP in /etc/sysconfig/cron that you can set to "yes" and that will delete any files in /tmp that don't belong to root whenever you reboot. Does Fedora have something equivalent to that? A quick Google didn't bring up anything.

Have you got a file /etc/init.d/halt.local ? If so you should put something like 'cd /tmp && rm -rf *' in there.
No, I don't have such a file. Is that a file the system makes, or can I just add it myself? I do have an /etc/init.d/halt.

BTW: I noticed a number of other contributors to the thread mentioned deleting at different runlevels. Was it via such a file that they did this?
 
Old 10-24-2009, 12:52 PM   #24
mejohnsn
Member
 
Registered: Sep 2009
Posts: 174

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
Whatever gave you the impression it would be "better" in any way?
Tmpwatch has checks built in to avoid race conditions and stuff.
This kludge has not.
YMMV(VM).
Ahem! I never said that it would be better. The way I phrased the question does not imply which I believe: that it is better or not. The way I phrased it actually suggests the opposite of what you assumed, the double question mark suggests that I thought it was not better.

Now that you have spoken out about the superiority of tmpwatch, I will use that instead of the 'kludge'. You have explained that it has necessary checks built in, an important fact that could take a long time to figure out from the man pages.

Thank you.
 
Old 10-24-2009, 01:06 PM   #25
mejohnsn
Member
 
Registered: Sep 2009
Posts: 174

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by catkin View Post
Regards "files that should not be removed on reboot" I am in the happy position of having a system on which it is OK for things to break if such files are removed, on which it is OK to experiment.
That's all very nice, but don't forget: the people who are reading your posts do not all make this assumption about their systems. You should not give advice that will break others's systems just because YOU are in a "happy position".

Tmpwatch may have a dizzying array of options, but at least it will not break anything.
 
Old 10-24-2009, 01:19 PM   #26
mejohnsn
Member
 
Registered: Sep 2009
Posts: 174

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
Simple question, simple answer, see: tmpwatch.
The answer does not still seem simple after looking at the man page for tmpwatch

For that matter, now that I have looked into it, I see that my Fedora11 system already has, by default, a crontab entry to call tmpwatch, yet the files are still slowly accumulating.

The call (in cron.daily) is:

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp

Now as I read this, this is a command to delete everything aged over 10 days in /tmp EXCEPT the explicitly named directories (well, I admit, I don't know what $flags is set to at the time).

But I see stuff that is obviously not in any of the above directories persisting in /tmp, such as virtual-mejohnsn.VRsASs, which is dated 2009-10-11, so it should have been deleted (over 10d ago).

So how do I go about figuring out why tmpwatch isn't deleting such files?

Last edited by mejohnsn; 10-24-2009 at 01:21 PM. Reason: add "aged over 10 days", ref. to cron.daily
 
Old 10-24-2009, 01:24 PM   #27
mejohnsn
Member
 
Registered: Sep 2009
Posts: 174

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by catkin View Post
Hi UnSpawn. What makes you call it a kludge?
The phrase you used, "does it's job without giving thought to other aspects", sets off a warning bell in any experienced programmer's head. That warning bell is the alarm bell warning of a kludge.

Besides that, he gave a better reason: that tmpwatch is designed to take into account ALL the necessary safeguards, the very safeguards people are usually ignoring when they say, "does it's job without giving thought to other aspects".

There is a world of a difference between ignoring side-effects and designing loosely-coupled code to avoid the need to consider side-effects.
 
Old 10-24-2009, 01:48 PM   #28
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Quote:
Originally Posted by mejohnsn View Post
That's all very nice, but don't forget: the people who are reading your posts do not all make this assumption about their systems. You should not give advice that will break others's systems just because YOU are in a "happy position".

Tmpwatch may have a dizzying array of options, but at least it will not break anything.
Thank you for your concern.

Deleting temporary files is always uncertain unless you have a thorough knowledge of everything that creates them -- and this is not practically acheivable.

Just because a file was created, modified or accessed more than <whatever> time ago does not mean that a badly written application will not break if the file is deleted. PID and lock files are good examples.

The end result is that deleting temporary files is always a gamble. Some sysadmins solve the problem by never deleting them. Others use the likes of tmpwatch or find to delete files according to age criteria -- with or without "delete all at boot".

In none of these scenarios (except never deleting) is the sysadmin 100% confident that nothing will ever break. Like scientific hypotheses -- that can never be proven correct but only falsified -- we can only become more confident as time and usage does not reveal any problems.

In this situation, with a newly installed system, it is a reasonable strategy to delete all temporary files at boot. I have done so without problem on every *n*x system I have been responsible for without ever having a problem. This principally on development server farms but including several production servers.

The only time I had a problem was when some developers had got into the habit of using /tmp as their personal dumping ground; that was solved by backing up before deletion and restoring to their home directories when they wanted their files back.

@mejohnsn You wrote "You should not give advice that will break others's systems". Quite right! And I don't think that I did although, of course, pretty much anything can cause breakage in unforeseen circumstances. Let's look at my post.

Quote:
Originally Posted by catkin View Post
For a system that is booted regularly are there and reasons for not deleting everything in /tmp as soon as it is mounted? I've modified /etc/rc.d/rc.S (this on Slackware 13.0) changing this original line
Code:
 ( cd /tmp && rm -rf kde-[a-zA-Z]* ksocket-[a-zA-Z]* hsperfdata_[a-zA-Z]* plugtmp* )
to
Code:
( cd /tmp && rm -rf * )
No breakage so far. On long uptime systems I used to remove anything more than 7 days old from a daily cron job. Half-expected some breakage but never had any.
I asked LQ if there were any reasons for not doing what I have implemented (without problem on multi-user servers around the globe including mission-critical servers), I showed how I had done it and reported "no breakage so far". That does not advise anyone to do it. It is not something that "will break others' systems" (although it may, of course, cause some breakage on some systems -- as may tmpwatch).
 
Old 10-25-2009, 04:00 AM   #29
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
Quote:
Originally Posted by mejohnsn View Post
The call (in cron.daily) is: (..) I admit, I don't know what $flags is set to at the time.
Your post is incomplete: if unsure best post complete, unedited cronjobs. The "$flags" variable is set at the top of the cronjob and holds the switches 'tmpwatch' uses to determine what checks to perform and what attributes to look at. This could for example be flags="-umc" to only look at (file) access, modification and change time or flags="-mMds" to perform a 'fuser' check on files (file in use or not), check file and directory modification time, and not remove directories.


Quote:
Originally Posted by mejohnsn View Post
But I see stuff that is obviously not in any of the above directories persisting in /tmp, such as virtual-mejohnsn.VRsASs, which is dated 2009-10-11, so it should have been deleted (over 10d ago). So how do I go about figuring out why tmpwatch isn't deleting such files?
First thing to check is what kind of file "/tmp/virtual-mejohnsn.VRsASs" is (run 'file' on it). To test removal for this purpose add the "-t" flag. This will make 'tmpwatch' go through the motions but without actually deleting things. If the file is not a regular file add "-a". Now to test things run:
Code:
/usr/sbin/tmpwatch -umcMdsta -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 10d /tmp 2>&1|grep -i vrsass
Tell us if the file does not show up.
 
Old 10-25-2009, 04:19 AM   #30
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,331
Blog Entries: 55

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
Quote:
Originally Posted by catkin View Post
I still prefer a "good enough" solution that does not require an extra package
Sure. Entirely your choice.


Quote:
Originally Posted by catkin View Post
if it has to be shut down (..) then wouldn't a serious investigation require disk imaging before any reboot?
Yes but that's not my point. It's about what tasks one may expect a system to perform on bootup. Yours wipes everything, without regard for anything and without a user being able to stop it.


I really would like to go into what you wrote later on, particularly the
Quote:
Originally Posted by catkin View Post
(without problem on multi-user servers around the globe including mission-critical servers)
part, but I think I've given you enough food for thought (which you're obviously free to ignore).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Can I delete files in /mnt/tmp? and Files in the trash can will not delete? M$ISBS Slackware 15 10-03-2009 12:56 AM
script to delete tmp files Iyyappan Linux - Newbie 8 08-02-2009 07:40 AM
Slackbuild files in /tmp. Ok to delete? Romanus81 Slackware 9 11-05-2008 10:45 PM
How To Delete tmp Files In FC5 zenarcher Fedora 3 09-07-2006 01:51 AM
can i delete /tmp files? demmylls Linux - General 1 03-01-2004 11:14 AM


All times are GMT -5. The time now is 09:01 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration