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 overwrit
> >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
> >s
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 l
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
> > 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
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 th
> 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 spa
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 pro
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, 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, ex
-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
>>> th
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 operation
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 " stuff in the
"cannot be attacked from the outsi
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 oth
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
-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
>>
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.
On Sun, Mar 25, 2007 at 10:00:46AM -0300, Jorge Peixoto de Morais Neto wrote:
> >
> >
> >The following little C program will illustrate:
> >
> >#include
> >#include
> >
> >int main(void) {
> > FILE *f;
> >
> > f = fopen("check_my_size", "w");
> > int i;
> > for (i = 0; i < 100; ++i)
> >
The following little C program will illustrate:
#include
#include
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")
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 bizar
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
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/
Warn
> >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? So
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
-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,
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
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?
> >> Destro
-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 i
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 destr
-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 ope
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 c
-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 tha
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 i
-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 crea
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 t
-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
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 u
-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 -m
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 -
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
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
-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
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 fil
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
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.
>From the FHS:
tmp : Temporary files
P
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.
>
> >From the FHS:
>
> tmp : Temporary files
>
> Purp
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, 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 w
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
50 matches
Mail list logo
