Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 06:40:01PM +, andy wrote: Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. Here's how I do it: 1. /tmp is on tmpfs so it automatically is gone on reboot. Yes the boot-up init-script also cleans out /tmp 2. swap (which then contains /tmp) is encrypted, on LVM, on raid1, and is large (twice my 1 GB ram) since disk space is cheap. 3. I use the libpam-tmpdir so that each user has their own tmp directory under /tmp/user 4. Each user has a symlink from /home/$USER/tmp to their actual temp dir, so that they can easily browse to their tmpdir. Also helpfull for some apps where you get a dialog to choose a cache directory and you can't directly enter a path but must browse to it. 5. TMP and TMPDIR are both set. I think this takes care of the users' tmp files. If they want to garbage-collect from their own $TMPDIR, let them. For non-user stuff, I just trust the debian team to make apps/packages that take care of this on their own. Do you find any specific files or file types in /tmp that worry you? YMMV. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
1. It is a lot faster for a lot of stuff, as long as your kernel has proper swapping behavior. This happens because tmpfs can avoid a great deal of costly operations that other filesystems with backing store need to perform (such as the need to keep metadata in sync on the backing store). 2. It will waste more virtual memory space than your regular filesystem with a backing store, as it needs to keep all data in virtual memory (even if it happens to be swapped). This *can* be a problem on 32-bit systems. On 26.03.07 18:41, Jorge Peixoto de Morais Neto wrote: Interesting. Is there any downside? if you (or your users if there are any) use /tmp for storing junk, you'll have less of memory. But after a few reboots it should stop Why isn't this default? there are still people (programs?) who don't know that /tmp is for TEMPORARY files and use ti that way. Also, filesystem design is usually on system administrator who does not know about these possibilities. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. M$ Win's are shit, do not use it ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/07 20:48, Henrique de Moraes Holschuh wrote: On Sat, 24 Mar 2007, Ron Johnson wrote: On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. That reminds me of the Vietnam War philosophy we had to destroy the village in order to save the village. It was bad design 40 years ago, it's a bad design now. No. You destroy the village in order for it not be able to bother you anymore, because you care a lot more about your objectives than the people in the village. And it is *excellent* design to unlink an open file depending on what you want it for. It is the only failure-proof way to make sure temporary files cannot be attacked from outside, and also that they will disappear if the program crashes, exits, or has other problems. You can easily change that to a unlink on sucessfull exit thing when running in debug mode, too. It's excellent only if your filesystem does not have rich-enough semantics to protect your files from outside snoops. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGB3vJS9HxQb37XmcRAjSyAJ46AboMCbnL58NTMMZpNMCRSN5yyACgj4ln bXIp6JISHhA532jpXiPj3Mo= =GM7k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Mon, 26 Mar 2007, Ron Johnson wrote: And it is *excellent* design to unlink an open file depending on what you want it for. It is the only failure-proof way to make sure temporary files cannot be attacked from outside, and also that they will disappear if the program crashes, exits, or has other problems. You can easily change that to a unlink on sucessfull exit thing when running in debug mode, too. It's excellent only if your filesystem does not have rich-enough semantics to protect your files from outside snoops. Sorry, but no. It is excellent because you never have to clean up after screw ups (the file will be gone as soon as it is closed or the process is terminated), and because it makes it impossible for incompetent programmers to access a file by anything other than its fd after it was created + unlinked. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On 25.03.07 23:32, Henrique de Moraes Holschuh wrote: On Sat, 24 Mar 2007, Jorge Peixoto de Morais Neto wrote: What is the performance impact of mounting /tmp in tmpfs? Some thoughts: 1. It is a lot faster for a lot of stuff, as long as your kernel has proper swapping behaviour. This happens because tmpfs can avoid a great deal of costly operations that other filesystems with backing store need to perform (such as the need to keep metadata in sync on the backing store). 2. It will waste more virtual memory space than your regular filesystem with a backing store, as it needs to keep all data in virtual memory (even if it happens to be swapped). This *can* be a problem on 32-bit systems. is virtual memory a problem on 32bit OS? I think even 32bit CPUs do have support for much larger _virtual_ memory. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Mon, Mar 26, 2007 at 08:27:22PM +0200, Matus UHLAR - fantomas wrote: is virtual memory a problem on 32bit OS? I think even 32bit CPUs do have support for much larger _virtual_ memory. With a 32-bit CPU, you are limited to 4 GB address space no matter what. Usually, it is 1 GB for the process and 3 GB for the kernel. There are patches available that make a 2/2 split possible. However, there are performance issues to consider. IIRC, even CPUs that have PAE (36-bit addressing for up to 64 GB of physical RAM), can still only support 4 GB address space *per process* because they are at heart 32-bit machines. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On Mon, Mar 26, 2007 at 08:27:22PM +0200, Matus UHLAR - fantomas wrote: is virtual memory a problem on 32bit OS? I think even 32bit CPUs do have support for much larger _virtual_ memory. On 26.03.07 14:35, Roberto C. Sánchez wrote: With a 32-bit CPU, you are limited to 4 GB address space no matter what. Usually, it is 1 GB for the process and 3 GB for the kernel. There are patches available that make a 2/2 split possible. However, there are performance issues to consider. IIRC, even CPUs that have PAE (36-bit addressing for up to 64 GB of physical RAM), can still only support 4 GB address space *per process* because they are at heart 32-bit machines. Yes, but that's just and only address space for one process. CPUs with PAE extension can have 64GB of REAL memory, so they can have at least that much of virtual memory. Note that tmpfs doesn't need to be addressable by one process. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Two words: Windows survives. - Craig Mundie, Microsoft senior strategist So does syphillis. Good thing we have penicillin. - Matthew Alton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Mon, Mar 26, 2007 at 09:07:50PM +0200, Matus UHLAR - fantomas wrote: On 26.03.07 14:35, Roberto C. Sánchez wrote: With a 32-bit CPU, you are limited to 4 GB address space no matter what. Usually, it is 1 GB for the process and 3 GB for the kernel. There are patches available that make a 2/2 split possible. However, there are performance issues to consider. IIRC, even CPUs that have PAE (36-bit addressing for up to 64 GB of physical RAM), can still only support 4 GB address space *per process* because they are at heart 32-bit machines. Yes, but that's just and only address space for one process. CPUs with PAE extension can have 64GB of REAL memory, so they can have at least that much of virtual memory. Note that tmpfs doesn't need to be addressable by one process. IIRC, even though you may have 4 GB of physical memory, your virtual memory space *per process* is limited to 4 GB. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On 26.03.07 14:35, Roberto C. Sánchez wrote: With a 32-bit CPU, you are limited to 4 GB address space no matter what. Usually, it is 1 GB for the process and 3 GB for the kernel. There are patches available that make a 2/2 split possible. However, there are performance issues to consider. IIRC, even CPUs that have PAE (36-bit addressing for up to 64 GB of physical RAM), can still only support 4 GB address space *per process* because they are at heart 32-bit machines. On Mon, Mar 26, 2007 at 09:07:50PM +0200, Matus UHLAR - fantomas wrote: Yes, but that's just and only address space for one process. CPUs with PAE extension can have 64GB of REAL memory, so they can have at least that much of virtual memory. Note that tmpfs doesn't need to be addressable by one process. On 26.03.07 15:11, Roberto C. Sánchez wrote: IIRC, even though you may have 4 GB of physical memory, your virtual memory space *per process* is limited to 4 GB. well, did I write something different? Wasn't I clear enough? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
1. It is a lot faster for a lot of stuff, as long as your kernel has proper swapping behavior. This happens because tmpfs can avoid a great deal of costly operations that other filesystems with backing store need to perform (such as the need to keep metadata in sync on the backing store). 2. It will waste more virtual memory space than your regular filesystem with a backing store, as it needs to keep all data in virtual memory (even if it happens to be swapped). This *can* be a problem on 32-bit systems. Interesting. Is there any downside? Why isn't this default? -- Software is like sex: it is better when it is free.
Re: deleting content of /tmp
On Mon, Mar 26, 2007 at 10:06:00PM +0200, Matus UHLAR - fantomas wrote: On Mon, Mar 26, 2007 at 09:07:50PM +0200, Matus UHLAR - fantomas wrote: Yes, but that's just and only address space for one process. CPUs with PAE extension can have 64GB of REAL memory, so they can have at least that much of virtual memory. Note that tmpfs doesn't need to be addressable by one process. On 26.03.07 15:11, Roberto C. Sánchez wrote: IIRC, even though you may have 4 GB of physical memory, your virtual memory space *per process* is limited to 4 GB. well, did I write something different? Wasn't I clear enough? I'm not sure. I guess that to me it sounded like it was possible to have 64 GB of virtual memory. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 11:25:08PM -0500, Ron Johnson wrote: tmpfile() Return a new file object opened in update mode (w+b). The file has no directory entries associated with it and will be automatically deleted once there are no file descriptors for the file. Availability: Macintosh, Unix, Windows. What I meant was os.tempnam(). Which the documentation indicates is vulnerable to symlink attacks. Not being able to exclusively lock a file is a definite weakness. Christ, no. It makes backups a buttload more complicated then they otherwise need be. I absolutely loathe backing up windows files beacuse of what mostlikely is a similar attitude. That's bad design. All in all I think you're making a mountain out of flat grass-plains here. There is nothing inherently faulty, false or wrong in what the zebra do there. For one, it makes sure that it is truly temporary. If the app exits in some bizare way then no harm done. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
mount /tmp onto tmpfs and run tmpreaper. No problems, just watch your swap space, limit its (/tmp) size and instead of separate partition for /tmp use bigger swap area. On 24.03.07 19:33, Jorge Peixoto de Morais Neto wrote: What is the performance impact of mounting /tmp in tmpfs? Some thoughts: 1) Maybe it will make the system faster, because files in tmp will be faster to access. 2) Then again, maybe the disk cache is enough for this, so there will be no impact on performance. there's no disk cache for tmpfs. The files stay in memory unless they are swapped out. There's no need to write data to disk unless you are short on memory, in which case they are swapped out. and I'd say swapping is more efficient than caching. There's no need for journalling, syncing each 5 or more seconds, and the structure is much more efficient since the files are not aligned onto filesystem block size. 3) Or, the system will be slower, because too much memory will be used for tmpfs and when some application needs memory the kernel will have to move a part of tmpfs to swap before it can serve the application. If you have many programs that fill up /tmp space for no reason, maybe. But I'm not sure because of reasons above - those data would be written to disk. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On 24.03.07 17:03, Raquel wrote: I use the following in my crontab. It gets rid of anything over a week old. # Remove old cache files 10 00 * * * find /tmp -type f -mtime +6 | xargs rm why not using tmpreaper? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On 24.03.07 23:25, Ron Johnson wrote: Apparently so. :( tmpfile() Return a new file object opened in update mode (w+b). The file has no directory entries associated with it and will be automatically deleted once there are no file descriptors for the file. Availability: Macintosh, Unix, Windows. What I meant was os.tempnam(). Which the documentation indicates is vulnerable to symlink attacks. ...just because it does have directory entry. and that's why passing open file without links is not vulnerable. Not being able to exclusively lock a file is a definite weakness. well, even if you would be able to exclusively lock a file, using such files is easy and effective way to get some security. Enterprise OSs give you much richer file semantics. But... they're heavier and slower. which OSes are you talking about? Ron, please stop it. This is an old, simle and safe strategy, definitely not a bug. The fact you don't understand it does not mean it's bad. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sun, Mar 25, 2007 at 08:01:39PM +1000, CaT wrote: All in all I think you're making a mountain out of flat grass-plains here. There is nothing inherently faulty, false or wrong in what the zebra do there. For one, it makes sure that it is truly temporary. If the app exits in some bizare way then no harm done. Good point. If the program creates huge temporary files and then promptly crashes, how do you get the space back? You'd have to delete the file. By the program unlinking it immediately after creation, it ensures that you get the disk space back no matter what. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
The following little C program will illustrate:
#include stdio.h
#include stdlib.h
int main(void) {
FILE *f;
f = fopen(check_my_size, w);
int i;
for (i = 0; i 100; ++i)
fprintf(f, This is just filler for the file);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Unlinking file\n);
fflush(stdout);
unlink(check_my_size);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Closing file\n);
fflush(stdout);
fclose(f);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
return 0;
}
Why do you use unlink() instead of remove()?
--
Software is like sex: it is better when it is free.
Re: deleting content of /tmp
On Sun, Mar 25, 2007 at 10:00:46AM -0300, Jorge Peixoto de Morais Neto wrote:
The following little C program will illustrate:
#include stdio.h
#include stdlib.h
int main(void) {
FILE *f;
f = fopen(check_my_size, w);
int i;
for (i = 0; i 100; ++i)
fprintf(f, This is just filler for the file);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Unlinking file\n);
fflush(stdout);
unlink(check_my_size);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Closing file\n);
fflush(stdout);
fclose(f);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
return 0;
}
Why do you use unlink() instead of remove()?
No difference, really:
If path specifies a directory, remove(path) is the equivalent of
rmdir(path). Otherwise, it is the equivalent of unlink(path).
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: deleting content of /tmp
If path specifies a directory, remove(path) is the equivalent of rmdir(path). Otherwise, it is the equivalent of unlink(path). I believe using unlink is less portable. -- Software is like sex: it is better when it is free.
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/07 05:01, CaT wrote: On Sat, Mar 24, 2007 at 11:25:08PM -0500, Ron Johnson wrote: tmpfile() Return a new file object opened in update mode (w+b). The file has no directory entries associated with it and will be automatically deleted once there are no file descriptors for the file. Availability: Macintosh, Unix, Windows. What I meant was os.tempnam(). Which the documentation indicates is vulnerable to symlink attacks. Not being able to exclusively lock a file is a definite weakness. Christ, no. It makes backups a buttload more complicated then they otherwise need be. I absolutely loathe backing up windows files beacuse of what mostlikely is a similar attitude. That's bad design. tar just doesn't have enough OS knowledge. OpenVMS BACKUP (as always, dependent on the process's privileges) only backs up closed files. BACKUP/INTERLOCK (still dependent on the process's privileges) has a special only-for-BACKUP feature that allows it access to open files. Dave Cutler must have forgotten that feature when designing Windows NT. BCKUP's /EXCLUDE syntax is also much nicer than tar --exclude, but that's a different story. All in all I think you're making a mountain out of flat grass-plains here. There is nothing inherently faulty, false or wrong in what the zebra do there. For one, it makes sure that it is truly temporary. If the app exits in some bizare way then no harm done. There are simple ways around that. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBpu6S9HxQb37XmcRAg2mAJ9LFksfbP6KP8iHI24CaxDulHOgLgCg3rYD 3T/f5d6YbC+qMyxzJO3Xb8c= =Kub/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sun, Mar 25, 2007 at 10:56:42AM -0500, Ron Johnson wrote: All in all I think you're making a mountain out of flat grass-plains here. There is nothing inherently faulty, false or wrong in what the zebra do there. For one, it makes sure that it is truly temporary. If the app exits in some bizare way then no harm done. There are simple ways around that. Yes. Delete the file and be done with it. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, 24 Mar 2007, Ron Johnson wrote: On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. That reminds me of the Vietnam War philosophy we had to destroy the village in order to save the village. It was bad design 40 years ago, it's a bad design now. No. You destroy the village in order for it not be able to bother you anymore, because you care a lot more about your objectives than the people in the village. And it is *excellent* design to unlink an open file depending on what you want it for. It is the only failure-proof way to make sure temporary files cannot be attacked from outside, and also that they will disappear if the program crashes, exits, or has other problems. You can easily change that to a unlink on sucessfull exit thing when running in debug mode, too. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sun, 25 Mar 2007, Henrique de Moraes Holschuh wrote: want it for. It is the only failure-proof way to make sure temporary files cannot be attacked from outside, and also that they will disappear if the Err, there are a lot of provided that foo doesn't happen stuff in the cannot be attacked from the outside. I should make that clear. Some of them I can recall immediately are: 1. Before you unlink the file, it can be attacked. Too bad we don't have a create an unlinked file operation (do we?), it is often what you want to do so that you can have backing store other than swap space... 2. After you unlink the file, that pesky /proc filesystem will still have a link to it for all processes in the same namespace as the process that created the file, and the file can be attacked through that link. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, 24 Mar 2007, Jorge Peixoto de Morais Neto wrote: What is the performance impact of mounting /tmp in tmpfs? Some thoughts: 1. It is a lot faster for a lot of stuff, as long as your kernel has proper swapping behaviour. This happens because tmpfs can avoid a great deal of costly operations that other filesystems with backing store need to perform (such as the need to keep metadata in sync on the backing store). 2. It will waste more virtual memory space than your regular filesystem with a backing store, as it needs to keep all data in virtual memory (even if it happens to be swapped). This *can* be a problem on 32-bit systems. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
deleting content of /tmp
Hi all Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. Your thoughts please ... Cheers /@ -- If they can get you asking the wrong questions, they don't have to worry about the answers. - Thomas Pynchon, Gravity's Rainbow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 06:40:01PM +, andy wrote: Hi all Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. It depends. If you are the only user of the machine and don't leave things running in the background when you log out, then it is very likely safe to do what you are talking about. If there are other users, it is almost certialy a bad thing, since you will invariably end in deleting some temporary socket or working file in there while someone is accessing it. I don't think it would be too bad, since as long as some process maintains an open file descriptor, the kernel won't remove the content. However, I would think it is better to not risk it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 06:40:01PM +, andy wrote: Hi all Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. It's been my experience that this happens by default on all of my debian (various flavors) systems. I'm not sure if it's done on shutdown or startup. I think this may be specified/suggested in the FHS, or maybe elsewhere. Try googling on delete /tmp or something... Ken -- Ken Irving, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 10:50:45AM -0800, Ken Irving wrote: On Sat, Mar 24, 2007 at 06:40:01PM +, andy wrote: Hi all Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. It's been my experience that this happens by default on all of my debian (various flavors) systems. I'm not sure if it's done on shutdown or startup. I think this may be specified/suggested in the FHS, or maybe elsewhere. Try googling on delete /tmp or something... I think I misunderstood the question, and confused logout w/ shutdown... -- Ken Irving, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. From the FHS: tmp : Temporary files Purpose The /tmp directory must be made available for programs that require temporary files. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. Rationale: IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard. So it is safe to delete /tmp when you know that no running programs are using any file there. You can delete /tmp in the beginning of the boot process, as the FHS itself suggests. I think this already happens automatically on Debian, but I'm not sure. -- Software is like sex: it is better when it is free.
Re: deleting content of /tmp
On Sat, 24 Mar 2007 16:12:10 -0300 Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. snip From the FHS: tmp : Temporary files Purpose The /tmp directory must be made available for programs that require temporary files. snip So it is safe to delete /tmp when you know that no running programs are using any file there. You can delete /tmp in the beginning of the boot process, as the FHS itself suggests. I think this already happens automatically on Debian, but I'm not sure. -- Several years ago I was using RedHat. It had a crontab which daily deleted any files in /tmp which were over a certain age. I have difficulty believing that any programs would hold onto any files that are a month old or possibly even a week old ... for a machine which does not reboot. -- Raquel Men are disturbed not by things, but by the view which they take of them. --Epictetus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
Raquel wrote: On Sat, 24 Mar 2007 16:12:10 -0300 Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. snip From the FHS: tmp : Temporary files Purpose The /tmp directory must be made available for programs that require temporary files. snip So it is safe to delete /tmp when you know that no running programs are using any file there. You can delete /tmp in the beginning of the boot process, as the FHS itself suggests. I think this already happens automatically on Debian, but I'm not sure. -- Several years ago I was using RedHat. It had a crontab which daily deleted any files in /tmp which were over a certain age. I have difficulty believing that any programs would hold onto any files that are a month old or possibly even a week old ... for a machine which does not reboot. Thank you all for your comments in response to my question. I tend to leave the machine running, but am the only user. I tend to default to the Gnome wm altho' do use XFce4 from time-to-time. For a machine that has an uptime of 6 days having a handful of some 23 items in the /tmp is not excessive, so is probably erased on shut down or boot up. This question of course could be answered by simply making a habit of shutting down regularly, which would be better on the environment too. Thanks all /@ -- If they can get you asking the wrong questions, they don't have to worry about the answers. - Thomas Pynchon, Gravity's Rainbow
Re: deleting content of /tmp
On 24.03.07 18:40, andy wrote: Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. I was thinking that it would be an okay thing to do periodically (or at logout, etc.) using a overwriting/shredding program. But, before I committed myself, decided it was prudent to ask. mount /tmp onto tmpfs and run tmpreaper. No problems, just watch your swap space, limit its (/tmp) size and instead of separate partition for /tmp use bigger swap area. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
mount /tmp onto tmpfs and run tmpreaper. No problems, just watch your swap space, limit its (/tmp) size and instead of separate partition for /tmp use bigger swap area. What is the performance impact of mounting /tmp in tmpfs? Some thoughts: 1) Maybe it will make the system faster, because files in tmp will be faster to access. 2) Then again, maybe the disk cache is enough for this, so there will be no impact on performance. 3) Or, the system will be slower, because too much memory will be used for tmpfs and when some application needs memory the kernel will have to move a part of tmpfs to swap before it can serve the application. -- Software is like sex: it is better when it is free.
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 15:27, andy wrote: [snip] I tend to leave the machine running, but am the only user. I tend to default to the Gnome wm altho' do use XFce4 from time-to-time. For a machine that has an uptime of 6 days having a handful of some 23 items in the /tmp is not excessive, so is probably erased on shut down or boot up. This question of course could be answered by simply making a habit of shutting down regularly, which would be better on the environment too. lsof(1) should be brought into play here. Any /tmp files older than 7 days but which are not found by lsof seem like reasonable candidates for deletion. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBa4lS9HxQb37XmcRAmBSAJ9QWcioJE6HOaHV4/AoCxdaU3XdAACfdfM2 J0ZZOaX/SfWhmeiDbp43W34= =8YkR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, 24 Mar 2007 20:27:45 + andy [EMAIL PROTECTED] wrote: Raquel wrote: On Sat, 24 Mar 2007 16:12:10 -0300 Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: Can someone advise me on the pros and cons of deleting the contents of /tmp/ as part of general security conscious non-paranoia. snip From the FHS: tmp : Temporary files Purpose The /tmp directory must be made available for programs that require temporary files. snip So it is safe to delete /tmp when you know that no running programs are using any file there. You can delete /tmp in the beginning of the boot process, as the FHS itself suggests. I think this already happens automatically on Debian, but I'm not sure. -- Several years ago I was using RedHat. It had a crontab which daily deleted any files in /tmp which were over a certain age. I have difficulty believing that any programs would hold onto any files that are a month old or possibly even a week old ... for a machine which does not reboot. Thank you all for your comments in response to my question. I tend to leave the machine running, but am the only user. I tend to default to the Gnome wm altho' do use XFce4 from time-to-time. For a machine that has an uptime of 6 days having a handful of some 23 items in the /tmp is not excessive, so is probably erased on shut down or boot up. This question of course could be answered by simply making a habit of shutting down regularly, which would be better on the environment too. Thanks all I use the following in my crontab. It gets rid of anything over a week old. # Remove old cache files 10 00 * * * find /tmp -type f -mtime +6 | xargs rm -- Raquel The Christian resolve to find the world evil and ugly, has made the world evil and ugly. --Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 05:03:44PM -0700, Raquel wrote: I use the following in my crontab. It gets rid of anything over a week old. # Remove old cache files 10 00 * * * find /tmp -type f -mtime +6 | xargs rm However, realize that some programs create a file /tmp and then promptly unlink it, thus causing the file to take up space even though it does not have a directory entry. This can be a problem if you have a long-running (as in longer than the interval over which your reaper runs) program. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On Sat, 24 Mar 2007 20:07:38 -0400 Roberto C. Sánchez [EMAIL PROTECTED] wrote: On Sat, Mar 24, 2007 at 05:03:44PM -0700, Raquel wrote: I use the following in my crontab. It gets rid of anything over a week old. # Remove old cache files 10 00 * * * find /tmp -type f -mtime +6 | xargs rm However, realize that some programs create a file /tmp and then promptly unlink it, thus causing the file to take up space even though it does not have a directory entry. This can be a problem if you have a long-running (as in longer than the interval over which your reaper runs) program. Regards, -Roberto Well, I guess that at that point I'll adjust the time period. Won't I? -- Raquel No one can terrorize a whole nation, unless we are all accomplices. --Edward R. Murrow
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 19:07, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 05:03:44PM -0700, Raquel wrote: I use the following in my crontab. It gets rid of anything over a week old. # Remove old cache files 10 00 * * * find /tmp -type f -mtime +6 | xargs rm However, realize that some programs create a file /tmp and then promptly unlink it, thus causing the file to take up space even though it does not have a directory entry. How's that? [snip] - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBdKuS9HxQb37XmcRAt4gAJ9QuMowCWRcDuRT+putegCxnvBANQCgzhcr lEcHgn4vFxRbxMcqvMCbupU= =JqTZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 08:38:54PM -0500, Ron Johnson wrote: However, realize that some programs create a file /tmp and then promptly unlink it, thus causing the file to take up space even though it does not have a directory entry. How's that? UNIX does not deallocate disk space until all opens are closed. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/24/07 20:45, CaT wrote:
On Sat, Mar 24, 2007 at 08:38:54PM -0500, Ron Johnson wrote:
However, realize that some programs create a file /tmp and then promptly
unlink it, thus causing the file to take up space even though it does
not have a directory entry.
How's that?
UNIX does not deallocate disk space until all opens are closed.
Sure, if there are {hard,soft} links on the file. What if it's a
no-links file?
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGBdZHS9HxQb37XmcRAlaOAJ9jvBhJAQwQkH+k682l7OIn8ebeTACgkix8
LwnAbXCUDAwqypENcP02vMg=
=jA/r
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 08:54:15PM -0500, Ron Johnson wrote:
On 03/24/07 20:45, CaT wrote:
On Sat, Mar 24, 2007 at 08:38:54PM -0500, Ron Johnson wrote:
However, realize that some programs create a file /tmp and then promptly
unlink it, thus causing the file to take up space even though it does
not have a directory entry.
How's that?
UNIX does not deallocate disk space until all opens are closed.
Sure, if there are {hard,soft} links on the file. What if it's a
no-links file?
If there is still an open file descriptor, it will still be there. The
disk space is only relinquished on the closing of all file descriptors.
The following little C program will illustrate:
#include stdio.h
#include stdlib.h
int main(void) {
FILE *f;
f = fopen(check_my_size, w);
int i;
for (i = 0; i 100; ++i)
fprintf(f, This is just filler for the file);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Unlinking file\n);
fflush(stdout);
unlink(check_my_size);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Closing file\n);
fflush(stdout);
fclose(f);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
return 0;
}
You just need to compare the df output for the partition on which the
program is running.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/24/07 21:22, Roberto C. Sánchez wrote:
On Sat, Mar 24, 2007 at 08:54:15PM -0500, Ron Johnson wrote:
On 03/24/07 20:45, CaT wrote:
On Sat, Mar 24, 2007 at 08:38:54PM -0500, Ron Johnson wrote:
However, realize that some programs create a file /tmp and then promptly
unlink it, thus causing the file to take up space even though it does
not have a directory entry.
How's that?
UNIX does not deallocate disk space until all opens are closed.
Sure, if there are {hard,soft} links on the file. What if it's a
no-links file?
If there is still an open file descriptor, it will still be there. The
disk space is only relinquished on the closing of all file descriptors.
The following little C program will illustrate:
#include stdio.h
#include stdlib.h
int main(void) {
FILE *f;
f = fopen(check_my_size, w);
int i;
for (i = 0; i 100; ++i)
fprintf(f, This is just filler for the file);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Unlinking file\n);
fflush(stdout);
unlink(check_my_size);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
sleep(2);
printf(Closing file\n);
fflush(stdout);
fclose(f);
system(ls -lk check_my_size);
printf(Checking utilization:\n);
fflush(stdout);
system(df -k);
return 0;
}
Ah, you're deleting an open file!
The app, then, that deletes an open file is poorly written.
You just need to compare the df output for the partition on which the
program is running.
Regards,
-Roberto
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGBd8eS9HxQb37XmcRAuarAKDBkAXd+oVtWOZUlHUfavXwk3ESmQCgoT89
rWwFhNRoQvtmDrayDPqc/58=
=PQjS
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 09:31:58PM -0500, Ron Johnson wrote: Ah, you're deleting an open file! The app, then, that deletes an open file is poorly written. On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 21:46, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 09:31:58PM -0500, Ron Johnson wrote: Ah, you're deleting an open file! The app, then, that deletes an open file is poorly written. On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. That reminds me of the Vietnam War philosophy we had to destroy the village in order to save the village. It was bad design 40 years ago, it's a bad design now. Regards, -Roberto - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBenIS9HxQb37XmcRAncqAJwMuz/P4ZZEBKBO2Uy6XqLs4UgBEACePYxU bDcbgJnOEIXbOImgWomx52s= =dzax -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 10:17:28PM -0500, Ron Johnson wrote: On 03/24/07 21:46, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 09:31:58PM -0500, Ron Johnson wrote: Ah, you're deleting an open file! The app, then, that deletes an open file is poorly written. On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. That reminds me of the Vietnam War philosophy we had to destroy the village in order to save the village. It was bad design 40 years ago, it's a bad design now. Out of curiousity, why do you say that it is a bad design? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 22:19, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 10:17:28PM -0500, Ron Johnson wrote: On 03/24/07 21:46, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 09:31:58PM -0500, Ron Johnson wrote: Ah, you're deleting an open file! The app, then, that deletes an open file is poorly written. On the contrary. It makes it so that the only way that someone can get to the file is by having cracked the kernel itself. That is, without the file descriptor, no other process can get to the data. For example, qemu does this. Lots of other programs do this as well for security. They open the file, immediately unlink it and then the only access is via the file descriptor. That reminds me of the Vietnam War philosophy we had to destroy the village in order to save the village. It was bad design 40 years ago, it's a bad design now. Out of curiousity, why do you say that it is a bad design? Destroying something to save it? - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBe2US9HxQb37XmcRAjSzAJ0RKQkjRDMlzsPpMFXZj9jFyi444gCg5MYq 9D8NRt2we29aFc1XTTkUJPY= =Cehu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 10:33:40PM -0500, Ron Johnson wrote: On 03/24/07 22:19, Roberto C. Sánchez wrote: Out of curiousity, why do you say that it is a bad design? Destroying something to save it? It seems like it makes perfect sense (in the temporary file case, not in the destroying a village case). If you know that the operating system will keep the file data allocated and allow you use the file as normal until you close it, then why not unlink it? It prevents collisions with naming and minimizes a vulnerability. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 22:36, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 10:33:40PM -0500, Ron Johnson wrote: On 03/24/07 22:19, Roberto C. Sánchez wrote: Out of curiousity, why do you say that it is a bad design? Destroying something to save it? It seems like it makes perfect sense (in the temporary file case, not in the destroying a village case). If you know that the operating system will keep the file data allocated and allow you use the file as normal until you close it, then why not unlink it? It prevents collisions with naming That's what, in python syntax, os.tmpfile() is for. and minimizes a vulnerability. A rich-enough file protection and locking protocol is supposed to handle that for you. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBfCAS9HxQb37XmcRAkXpAKCp2Fp5MG5zuCLgbRAu7G+AjZZPZQCfUEdP Ug3f0XcVYNovbe0owh70ceg= =mnuF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 10:46:08PM -0500, Ron Johnson wrote: On 03/24/07 22:36, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 10:33:40PM -0500, Ron Johnson wrote: On 03/24/07 22:19, Roberto C. Sánchez wrote: Out of curiousity, why do you say that it is a bad design? Destroying something to save it? It seems like it makes perfect sense (in the temporary file case, not in the destroying a village case). If you know that the operating system will keep the file data allocated and allow you use the file as normal until you close it, then why not unlink it? It prevents collisions with naming That's what, in python syntax, os.tmpfile() is for. Right. I have used that before. and minimizes a vulnerability. A rich-enough file protection and locking protocol is supposed to handle that for you. Well, C is a very austere language. You have to implement lots of functionality yourself. I mean, it doesn't have garbage collection and people don't complain so much about it. Or maybe they do, but they realize that such functionality needs to be implemented somehow, so some language must lack it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: deleting content of /tmp
On Sat, Mar 24, 2007 at 10:46:08PM -0500, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 22:36, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 10:33:40PM -0500, Ron Johnson wrote: On 03/24/07 22:19, Roberto C. Sánchez wrote: Out of curiousity, why do you say that it is a bad design? Destroying something to save it? It seems like it makes perfect sense (in the temporary file case, not in the destroying a village case). If you know that the operating system will keep the file data allocated and allow you use the file as normal until you close it, then why not unlink it? It prevents collisions with naming That's what, in python syntax, os.tmpfile() is for. and minimizes a vulnerability. A rich-enough file protection and locking protocol is supposed to handle that for you. I wonder how the python run-time package actually implements an os.tmpfile on a *nix system --- maybe by creating a file and then unlinking it? -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deleting content of /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 23:07, Paul E Condon wrote: On Sat, Mar 24, 2007 at 10:46:08PM -0500, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/07 22:36, Roberto C. Sánchez wrote: On Sat, Mar 24, 2007 at 10:33:40PM -0500, Ron Johnson wrote: On 03/24/07 22:19, Roberto C. Sánchez wrote: Out of curiousity, why do you say that it is a bad design? Destroying something to save it? It seems like it makes perfect sense (in the temporary file case, not in the destroying a village case). If you know that the operating system will keep the file data allocated and allow you use the file as normal until you close it, then why not unlink it? It prevents collisions with naming That's what, in python syntax, os.tmpfile() is for. and minimizes a vulnerability. A rich-enough file protection and locking protocol is supposed to handle that for you. I wonder how the python run-time package actually implements an os.tmpfile on a *nix system --- maybe by creating a file and then unlinking it? Apparently so. :( tmpfile() Return a new file object opened in update mode (w+b). The file has no directory entries associated with it and will be automatically deleted once there are no file descriptors for the file. Availability: Macintosh, Unix, Windows. What I meant was os.tempnam(). Which the documentation indicates is vulnerable to symlink attacks. Not being able to exclusively lock a file is a definite weakness. Enterprise OSs give you much richer file semantics. But... they're heavier and slower. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGBfmkS9HxQb37XmcRAlPFAJ9bHBWobMPXi9uj+eD+/1culPNCJACfY0qW EU3XvvbwfeXrP6LWMg/Lkw0= =GjCc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
