Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero. -- Vratislav Podzimek vpodz...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 2 April 2012 20:58, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Does this have any implications for polyinstantiated tmp directories? As far as I can see, it should cause no problems as pam_namespace has an option for tmpfs tmp directories. But I thought it worth asking. Jonathan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 08:58:12PM +0100, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... +1 The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work - quota, the generic tmpfs problem... Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
drago01 wrote: We could just make anaconda remove everything in /tmp ... done. First of all, renaming it as Simo Sorce suggested makes more sense. But secondly, what you both miss is that not everyone upgrades using Anaconda, there's also plain yum. Seeing more and more black magic getting added to Anaconda to deal with pointless arcane incompatible file system changes really makes me cringe. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Wed, Apr 04, 2012 at 11:51:08AM +0200, Kevin Kofler wrote: drago01 wrote: We could just make anaconda remove everything in /tmp ... done. First of all, renaming it as Simo Sorce suggested makes more sense. But secondly, what you both miss is that not everyone upgrades using Anaconda, there's also plain yum. Seeing more and more black magic getting Fot those scenarios, there is wiki page. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Wed, 04.04.12 09:31, Jonathan Underwood (jonathan.underw...@gmail.com) wrote: On 2 April 2012 20:58, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Does this have any implications for polyinstantiated tmp directories? As far as I can see, it should cause no problems as pam_namespace has an option for tmpfs tmp directories. But I thought it worth asking. It should just continue to work as it always did. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Tue, Apr 3, 2012 at 5:10 AM, Kevin Kofler kevin.kof...@chello.at wrote: Richard W.M. Jones wrote: Actually I think this is a good feature, but ... I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.) We could just make anaconda remove everything in /tmp ... done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Tue, 2012-04-03 at 05:10 +0200, Kevin Kofler wrote: Richard W.M. Jones wrote: Actually I think this is a good feature, but ... I'm unsure about whether this makes sense for new installs or not, but I feel my objection in https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into account at all. :-/ Forcing this change on upgrades will leave users with wasted disk space they cannot easily reclaim. (For us technical users, reclaiming it will be complicated, for non-technical users, it will be impossible.) Can't this be easily resolved by renaming /tmp -/old-tmp at upgrade time ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 04/02/2012 15:58, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw I really need to remember to send with the right user identity for this list. resend of my message since its going to bounce That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote: On 04/02/2012 15:58, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw I really need to remember to send with the right user identity for this list. resend of my message since its going to bounce That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes. That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't support user.* at all AFAICT. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 04/02/2012 16:06, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote: On 04/02/2012 15:58, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk - it doesn't support O_DIRECT - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw I really need to remember to send with the right user identity for this list. resend of my message since its going to bounce That third part is not correct. tmpfs supports SELinux labels. If you mount a tmpfs filesystem you'll see it reports seclabel as one of the mount options. You can also just use chcon -t to set the type on any file you like. SELinux labels are stored in the security namespace which is separate from user extended attributes. That's not what I said. I said that relatively recent kernels (up to the middle of last year) didn't support system.*, and tmpfs doesn't support user.* at all AFAICT. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top I wasn't contesting your statement of user.* and system.* I was just pointing out that tmpfs has supported SELinux labels for a very long time. Even well before Eric's patch last year that put generic xattr handlers in. So there should be no issue at all with SELinux labels on tmpfs even if you run older kernels. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk Which does not really matter in practice. - it doesn't support O_DIRECT Neither does this (which apps needs O_DIRECT on /tmp ? ). - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work Huh? Why would you run a very old kernel on fedora? All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. Sure if bugs are found they should be fixed. But note I have been doing this testing for a *long* time (long as in years) on different systems and yet have to find a package that breaks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 02.04.12 20:58, Richard W.M. Jones (rjo...@redhat.com) wrote: Heya, The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. Well, i'd claim this is not really user visible if implemented correctly. This is however visible to the developer. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk Yes, large files need to be placed on /var/tmp, which is explained in the feature page. - it doesn't support O_DIRECT Well, all code using O_DIRECT should probably have a fallback to work without, anyway, and very likely has. O_DIRECT doesn't really make sense for tmpfs, it isn't really a feature that currently isn't supported and could be implemented, it is something that genuinly makes little sense for tmpfs... - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work We do this change for F18, not for old Fedora with old kernels. SELinux labels work fine on tmpfs. User xattr patches have recently been posted on lkml, but indeed are not supported right now. All this means it's going to need a bit more testing, since potentially any package that stores a file on /tmp should be tested and may need to be fixed. But yes, this is absolutely true. We do expect breakages. That's why our plan is: Turn on early in the F18 cycle. Fix bugs which appear as they show up. If they are too many, revert to turned off. I will post a longer annoucnement of this with suggested fixes to fedora-devel when we make the upload to turn this on for F18. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 10:24:38PM +0200, drago01 wrote: On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones rjo...@redhat.com wrote: - it doesn't support O_DIRECT Neither does this (which apps needs O_DIRECT on /tmp ? ). qemu and libguestfs as it turned out. It was one of the things we had to fix when we first ported to Debian. It's not completely unusual that an application should want to directly access a cache file, bypassing the page cache, nor that it would want to store such a file in /tmp. My point was that these things will be discovered when we test every application. - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work Huh? Why would you run a very old kernel on fedora? It's not unknown that people use different kernels from the ones supplied. I said not very old, by which I meant = 12 months old. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 02.04.12 21:30, Richard W.M. Jones (rjo...@redhat.com) wrote: - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work Huh? Why would you run a very old kernel on fedora? It's not unknown that people use different kernels from the ones supplied. I said not very old, by which I meant = 12 months old. SELinux on tmpfs has been supported at least as long as we made devtmpfs the default on Fedora, since that's more or less just a tmpfs like any other when it comes to features. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 04:40:38PM -0400, David Quigley wrote: You don't specify seclabel as an option. It is something that is put into the mount command to show you that a filesystem supports being able to set security labels on it. OK, I see. In fact I tested this and I was able to set SELinux labels on RHEL 5 tmpfs, so this does work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote: On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. /tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
Richard W.M. Jones (rjo...@redhat.com) said: - it doesn't support user extended attrs; and not very old kernels didn't support any xattrs at all, meaning things like SELinux labels don't work Huh? Why would you run a very old kernel on fedora? It's not unknown that people use different kernels from the ones supplied. I said not very old, by which I meant = 12 months old. That doesn't mean they're not voiding their (admittedly nonexistent) warranty when they do so. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, Apr 02, 2012 at 20:58:12 +0100, Richard W.M. Jones rjo...@redhat.com wrote: - it doesn't support O_DIRECT I thought this was also true of ext4 with data journaling enabled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On 2 April 2012 14:55, Steve Grubb sgr...@redhat.com wrote: On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. I would guess it is a tossup. Depending on the security plan.. systems may want stuff in tmpfs to not allow for stuff to be around for a reboot (in the case where physical access after a reboot could compromise tokens and such). Other security plans required tmpfs to be turned off for forensics. Many of the break-in kits though use /dev/shm already so they aren't going to be around after a reboot. I would expect that any turn-on/turn-off of tmpfs would need to be configurable so that users who needed one or the other could get it. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 2 Apr 2012, Lennart Poettering wrote: On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote: What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. /tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up. there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics. This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
* M A Young [02/04/2012 23:51] : This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes. The expectations of these 'many' (this really needs to be measured) run counter to the LSB recommendation for /tmp . 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. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
