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
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).
-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
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
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
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
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
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
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
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.
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
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
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
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:
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
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
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
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
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.
-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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
-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
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
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
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 |
-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 |
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
-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
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
-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
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,
-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
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
-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!
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
-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
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
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
-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
51 matches
Mail list logo
