Linux - NewbieThis 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
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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).
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).
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 ...
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
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?
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
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?
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?
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.
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.
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.
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 12:21 PM.
Reason: add "aged over 10 days", ref. to cron.daily
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.
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
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
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).
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
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:
I still prefer a "good enough" solution that does not require an extra package
Sure. Entirely your choice.
Quote:
Originally Posted by catkin
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
(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).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.