Re: autoclean mode for tmpfs
On Sun 07 Aug 2011 at 18:04:43 +0200, Emmanuel Dreyfus wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. If it were done at the next directory listing attempt, it would make more sense (and the removed file should not be reported as present of course). In the mean time, a program which may have created the file and remembered its name, may still access it past the expiration date if it is lucky (i.e., nobody looked - a quantum file system where observation changes the files). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: autoclean mode for tmpfs
Rhialto rhia...@falu.nl wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. If it were done at the next directory listing attempt, it would make more sense (and the removed file should not be reported as present of course). In the mean time, a program which may have created the file and remembered its name, may still access it past the expiration date if it is lucky (i.e., nobody looked - a quantum file system where observation changes the files). Well, I meant on the next lookup, actually, but readdir should also kill it. This is probably too complicated. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: autoclean mode for tmpfs
On Tue, Aug 09, 2011 at 07:13:44PM +0200, Emmanuel Dreyfus wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. If it were done at the next directory listing attempt, it would make more sense (and the removed file should not be reported as present of course). In the mean time, a program which may have created the file and remembered its name, may still access it past the expiration date if it is lucky (i.e., nobody looked - a quantum file system where observation changes the files). Well, I meant on the next lookup, actually, but readdir should also kill it. This is probably too complicated. Quite a bit more complicated than just arming a timeout for every vnode or something like that, yes... -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
On Sun, 7 Aug 2011, David Holland wrote: On Sun, Aug 07, 2011 at 06:29:01PM +0200, Marc Balmer wrote: And what is auto-erasing files good for in the first place? I don't get the point, for me it's calling for trouble. Traditionally, it's so /tmp doesn't grow without bound, which once upon a time was a problem with small root partitions or ramdisks. What processes leave data in /tmp? perhaps they should be fixed instead, to clean up after themselves.. I actively use /tmp as a work area so I notice when it builds up, but I guess using things like magic symlinks to provide a per-user tmp storage (or however that works :) can hide the real size of /tmp in multi-user systems. The biggest offender I see is that build.sh sometimes leaves /tmp/config.* directories around which I clean out, but not sure if thats only when it is interrupted or fails.. iain
Re: autoclean mode for tmpfs
Hello. I don't know about others, but I rely heavily on the daily and weekly scripts to clean out /tmp and /var/tmp, and have done so for many years. I'm always creating temporary files I don't need for long periods of time, but don't want them to necessarily disappear immediately. The cleaners do this for me by insuring that if the files aren't access for 3 days in /tmp or 7 days in /var/tmp, they are magically removed. I know this behavior exists, and things that need to stay around permanently get put in their appropriate location. With the cleaner in place, I get a grace period to decide whether it is permanent or not. It sounds like the cleaning scripts may need to be modified to clean the common directory spaces more safely, but that the current filesysten operations do provide a way for those scripts to clean safely. I'd rather see the scrips changed to behave safely rather than a bunch of filesystem calls and/or functional changes made at the filesystem level to solve a problem which it seems could be argued may or may not exist in the current environment. I'm not a user of tmpfs, but I assume it implements the sticky-bit append-only functionality of the ufs filesystems? If not, then perhaps putting that in place would solve most of the issues? -Brian On Aug 8, 8:48am, Iain Hibbert wrote: } Subject: Re: autoclean mode for tmpfs } On Sun, 7 Aug 2011, David Holland wrote: } } On Sun, Aug 07, 2011 at 06:29:01PM +0200, Marc Balmer wrote: }And what is auto-erasing files good for in the first place? I don't get }the point, for me it's calling for trouble. } } Traditionally, it's so /tmp doesn't grow without bound, which once } upon a time was a problem with small root partitions or ramdisks. } } What processes leave data in /tmp? perhaps they should be fixed instead, } to clean up after themselves.. } } I actively use /tmp as a work area so I notice when it builds up, but I } guess using things like magic symlinks to provide a per-user tmp storage } (or however that works :) can hide the real size of /tmp in multi-user } systems. } } The biggest offender I see is that build.sh sometimes leaves /tmp/config.* } directories around which I clean out, but not sure if thats only when it } is interrupted or fails.. } } iain -- End of excerpt from Iain Hibbert
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 03:10:29AM +, David Holland wrote: So I just had an idea: since cleaning /tmp on a live system is very dangerous unless done so (and even then somewhat dangerous), plus there are other possible uses for automatically disappearing files: How hard would it be to add a mount option for tmpfs to automatically drop files after a given timeout? It seems to me that it shouldn't be very difficult, but I haven't looked at the tmpfs innards in a while. Anyone think this is worthwhile? Sounds like a job for the userland and cron(8). - Jukka.
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 09:25:59AM +0300, Jukka Ruohonen wrote: On Sun, Aug 07, 2011 at 03:10:29AM +, David Holland wrote: So I just had an idea: since cleaning /tmp on a live system is very dangerous unless done so (and even then somewhat dangerous), plus there are other possible uses for automatically disappearing files: How hard would it be to add a mount option for tmpfs to automatically drop files after a given timeout? It seems to me that it shouldn't be very difficult, but I haven't looked at the tmpfs innards in a while. Anyone think this is worthwhile? Sounds like a job for the userland and cron(8). uh no. See: since cleaning /tmp on a live system is very dangerous -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 07:09:14AM +, David Holland wrote: Sounds like a job for the userland and cron(8). uh no. See: since cleaning /tmp on a live system is very dangerous So care to elaborate what is dangerous about it? I do clean /tmp daily, but it needs to be done selectively. - Jukka.
Re: autoclean mode for tmpfs
How hard would it be to add a mount option for tmpfs to automatically drop files after a given timeout? Anyone think this is worthwhile? Sounds like a job for the userland and cron(8). Sort of. Personally? I'd say that scheduling it should be done by userland, but that putting the actual removal in the filesystem makes sense. I'm not sure whether I'd prefer to do it with a new and idiosyncratic syscall, a vfs.something sysctl, some sort of filesystem-level analog to ioctl, or what. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 10:40:00AM +0300, Jukka Ruohonen wrote: Sounds like a job for the userland and cron(8). uh no. See: since cleaning /tmp on a live system is very dangerous So care to elaborate what is dangerous about it? It's a security FAQ. If you do rm -rf (or nearly any of the other obvious/easy alternatives) in a world-writable directory, a hostile user can interact with it to erase any file on the system. -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
Mouse mo...@rodents-montreal.org wrote: Personally? I'd say that scheduling it should be done by userland, but that putting the actual removal in the filesystem makes sense. Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: autoclean mode for tmpfs
It's a security FAQ. If you do rm -rf (or nearly any of the other obvious/easy alternatives) in a world-writable directory, a hostile user can interact with it to erase any file on the system. I believe that this is partially fixable: provided there is at least one file descriptor available per directory level, I think it is possible to safely remove everything but directories. Most briefly, fchdir to each directory, stat . and make sure it matches the directory we thought we chdired into (to avoid doing damage if we lose a symlink race). Then delete things using relative-to-. paths and fchdir back out. However, since there's no way to make rmdir(2) use NOFOLLOW, we have to either leave directory structure in place or risk removing an attacker's choice of empty directories. Not that this makes it any easier to do the usual find | xargs rm style of cleanup, though. To do it safely in the way I refer to above would require doing it all inside rm. Might be worth doing, but quite possibly better done in the filesystem, to (a) avoid the need for the file descriptors, (b) delete a file here and a file there rather than the wholesale destruction of rm -rf (even if I'm right about it being possible to make it safe against hostile users), and (c) get directories right. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: autoclean mode for tmpfs
Marc Balmer mbal...@netbsd.org wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. you shoudn't toss away a file when something attempts to access it. you should toss it away when nothing attempt to access it for long enough. The idea was to avoid a daemon that periodically inspets file timeout. You just have to check for expiration on access. If expired, remove the file and ansswer ENOENT. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: autoclean mode for tmpfs
Am 07.08.11 18:34, schrieb Emmanuel Dreyfus: Marc Balmer mbal...@netbsd.org wrote: Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. you shoudn't toss away a file when something attempts to access it. you should toss it away when nothing attempt to access it for long enough. The idea was to avoid a daemon that periodically inspets file timeout. You just have to check for expiration on access. If expired, remove the file and ansswer ENOENT. But that is uber-stupid ;) Something tries to access a file, which is perfectly there, and instead of returning the data, we toss the data away and return ENOENT... ??? Sorry, but this is really a bad idea. What's wrong with having a kernel thread that those the house-keeping? And what is auto-erasing files good for in the first place? I don't get the point, for me it's calling for trouble.
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 06:29:01PM +0200, Marc Balmer wrote: And what is auto-erasing files good for in the first place? I don't get the point, for me it's calling for trouble. Traditionally, it's so /tmp doesn't grow without bound, which once upon a time was a problem with small root partitions or ramdisks. Another possible use is for files you explicitly want to make transient, like say /var/rwho (not that anyone uses rwhod any more) or /usr/pkgsrc/packages or /var/crash or a subtree you point coredumps into. Or whatever. -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
Marc Balmer mbal...@netbsd.org wrote: But that is uber-stupid ;) Something tries to access a file, which is perfectly there, and instead of returning the data, we toss the data away and return ENOENT... ??? If I understood correctly the idea, you do this if your temporary file has expired its TTL. The idea is to have temporary file that vanish on their own, right? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 12:11:49PM -0400, Mouse wrote: It's a security FAQ. If you do rm -rf (or nearly any of the other obvious/easy alternatives) in a world-writable directory, a hostile user can interact with it to erase any file on the system. I believe that this is partially fixable: provided there is at least one file descriptor available per directory level, I think it is possible to safely remove everything but directories. Most briefly, fchdir to each directory, stat . and make sure it matches the directory we thought we chdired into (to avoid doing damage if we lose a symlink race). Then delete things using relative-to-. paths and fchdir back out. I'd suggest that anyone interested in this look into (perhaps the history of) Red Hat's tmpwatch, which does roughly this but was also overengineered and thrashed on until believed safe by the security community. It forks for every level; I don't remember if this is because a subtle problem that arises if you don't or if it's just because linux doesn't/didn't handle fchdir correctly. It's been a while... However, since there's no way to make rmdir(2) use NOFOLLOW, we have to either leave directory structure in place or risk removing an attacker's choice of empty directories. ? valkyrie% ls -l total 4 drwx-- 2 dholland notmp 512 Aug 7 12:32 bar lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar valkyrie% rmdir baz rmdir: baz: Not a directory Exit 1 valkyrie% Not that this makes it any easier to do the usual find | xargs rm style of cleanup, though. To do it safely in the way I refer to above would require doing it all inside rm. Might be worth doing, but quite possibly better done in the filesystem, to (a) avoid the need for the file descriptors, (b) delete a file here and a file there rather than the wholesale destruction of rm -rf (even if I'm right about it being possible to make it safe against hostile users), and (c) get directories right. Right. (particularly in tmpfs, since tmpfs is already for transient data) -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 06:59:32PM +0200, Emmanuel Dreyfus wrote: But that is uber-stupid ;) Something tries to access a file, which is perfectly there, and instead of returning the data, we toss the data away and return ENOENT... ??? If I understood correctly the idea, you do this if your temporary file has expired its TTL. The idea is to have temporary file that vanish on their own, right? Yes, but if they don't actually go away without explicit intervention it mostly defeats the purpose... -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
Am 07.08.11 18:59, schrieb Emmanuel Dreyfus: Marc Balmer mbal...@netbsd.org wrote: But that is uber-stupid ;) Something tries to access a file, which is perfectly there, and instead of returning the data, we toss the data away and return ENOENT... ??? If I understood correctly the idea, you do this if your temporary file has expired its TTL. The idea is to have temporary file that vanish on their own, right? If at all, I think it only makes sense if a file vanishes on its own, thus freeing space. If nothing ever accesses it, it will forever use up space. But then, I don't think that filesystems should become to intelligent and tinker with their content on themselves (with maybe the exception of some filesystems that are designed for this, devfs, ptyfs etc. /tmp is none of these and should best be left alone, imo)
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 03:10:29AM +, David Holland wrote: So I just had an idea: since cleaning /tmp on a live system is very dangerous unless done so (and even then somewhat dangerous). There is nothing inherently dangerous in removing a directory tree. It is possible for an attacker to prevent the termination, but it is quite easy to ensure that it works correct. Joerg
Re: autoclean mode for tmpfs
However, since there's no way to make rmdir(2) use NOFOLLOW, [...] ? lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar valkyrie% rmdir baz rmdir: baz: Not a directory ! Hm, I see that too. I wonder where I got the idea it followed symlinks. My apologies for spreading misinformation. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 04:51:39PM +, David Holland wrote: On Sun, Aug 07, 2011 at 12:11:49PM -0400, Mouse wrote: However, since there's no way to make rmdir(2) use NOFOLLOW, we have to either leave directory structure in place or risk removing an attacker's choice of empty directories. ? valkyrie% ls -l total 4 drwx-- 2 dholland notmp 512 Aug 7 12:32 bar lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar valkyrie% rmdir baz rmdir: baz: Not a directory Exit 1 My guess for steps to create the problem is: % mkdir /tmp/foo/bar % make-lots-of-files-in-dir /tmp/foo/bar % run-job-that-slows-down-the-system % wait-for-tmp-cleanup-to-start % mv /tmp/foo /tmp/foo2 % ln -s /some/path /tmp/foo ... and the tmp cleanup does a rmdir /tmp/foo/bar, which is actually /some/path/bar instead. eric
Re: autoclean mode for tmpfs
On Sun, 7 Aug 2011 18:04:43 +0200 m...@netbsd.org (Emmanuel Dreyfus) wrote: Mouse mo...@rodents-montreal.org wrote: Personally? I'd say that scheduling it should be done by userland, but that putting the actual removal in the filesystem makes sense. Yes, a TTL attribute on an inode: once it expires, the filesystem tosses the file on next access attempt. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org Thats a horrible idea. Please think over. :-) -- NetBSD - Simplicity is prerequisite for reliability Software Engineering Department, University of Szeged
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 01:54:01PM -0500, Eric Haszlakiewicz wrote: However, since there's no way to make rmdir(2) use NOFOLLOW, we have to either leave directory structure in place or risk removing an attacker's choice of empty directories. ? valkyrie% ls -l total 4 drwx-- 2 dholland notmp 512 Aug 7 12:32 bar lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar valkyrie% rmdir baz rmdir: baz: Not a directory Exit 1 My guess for steps to create the problem is: % mkdir /tmp/foo/bar % make-lots-of-files-in-dir /tmp/foo/bar % run-job-that-slows-down-the-system % wait-for-tmp-cleanup-to-start % mv /tmp/foo /tmp/foo2 % ln -s /some/path /tmp/foo ... and the tmp cleanup does a rmdir /tmp/foo/bar, which is actually /some/path/bar instead. If you traverse the tree as Mouse described, it won't do that. If you don't, there are a lot of ways to abuse it. -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
On Sun, Aug 07, 2011 at 02:48:14PM -0400, Mouse wrote: lrwx-- 1 dholland notmp3 Aug 7 12:32 baz - bar valkyrie% rmdir baz rmdir: baz: Not a directory ! Hm, I see that too. I wonder where I got the idea it followed symlinks. Probably because in sys_rmdir: NDINIT(nd, DELETE, LOCKPARENT | LOCKLEAF | TRYEMULROOT, pb); however: #define FOLLOW 0x0040 /* follow symbolic links */ #define NOFOLLOW0x /* do not follow symbolic links (pseudo) */ This is one of the reasons behavior like this should be controlled by booleans or enums rather than flags... My apologies for spreading misinformation. I was worried for a moment :-) -- David A. Holland dholl...@netbsd.org
Re: autoclean mode for tmpfs
On 2011-08-07 18.38, David Holland wrote: On Sun, Aug 07, 2011 at 06:29:01PM +0200, Marc Balmer wrote: And what is auto-erasing files good for in the first place? I don't get the point, for me it's calling for trouble. Traditionally, it's so /tmp doesn't grow without bound, which once upon a time was a problem with small root partitions or ramdisks. Another possible use is for files you explicitly want to make transient, like say /var/rwho (not that anyone uses rwhod any more) or /usr/pkgsrc/packages or /var/crash or a subtree you point coredumps into. Or whatever. I use rwhod. :-) And it would not be a good idea to clean that automatically. It also gives information on how long a machine have been down... But I can see the occasional use for files with an expire time. Not sure that I'd use it, though. Cleaning out /tmp works fine using sticky bits and the occasional manual cleaning, if needed, for me. Not that I can remember actually ever having had to clean /tmp, but I bet I've done it at some point. Johnny
