Re: Setting up automatic delete

From: wave++ (wavexx_at_oblio.yuv.info)
Date: 12/03/03 

Date: 3 Dec 2003 09:23:01 GMT

On 2003-12-03, Ivan Rayner <ivanr@sgi.com> wrote:
>>|> Yes, forgot about spaces as I don't have to handle them usually :).
>>>> Using xargs however should be faster. If you have GNU utilities in place
>>|> you could do this:
>>
>>|> find ... -print0 | xargs -0 rm -f
>>
>>
>>| % mkdir delete_etc
>>| % for i in `seq 1 10000` ; do touch delete_etc/$i; done
>>| % touch delete_etc/passwd
>>| (have fam monitor and notify when files are being deleted
>>| from this dir)
>>| % mv delete_etc delete_etc-
>>| % ln -s /etc delete_etc
>>
>>|Whoops, where did my /etc/passwd go?
>>
>> Took me a bit of time to understand what's going on in Jan-Frode's code.
>>
>> The idea is that you create a file and leave it sitting around long
>> enough to be subject to the automatic cleaning. The 'find' process
>> will discover the name of the file, but will not, in the 'xargs' form
>> above, immediately delete the file; it will simply at first record
>> the file name. Then, after the name has been recorded and the deletions
>> start, you race the deletion section of the xargs and subtitute
>> a symbolic link at the -directory- level above. The rm is just fed
>> the -name- of the file+directory, so it goes ahead and follows
>> the symbolic link over to new location (not having been told that
>> it used to be a real directory before instead of a symlink),
>> and what gets deleted is the system file, not the user file. :(

A _true_ solution would consist in stat(2)-ing all files encountered
during the recursive scan to record inodes, and then verifing them when
removing the files themselves. As a futher optimization you can verify
inodes only on directories.

The problem however could still persist if you moved some files around
when scanning (assuming you unlink files immediately, you may still have
problems on large directory trees). You have to double-check that all
files resides inside the root you specify.

> Since find wouldn't follow symlinks, all you'd need to do is replace
> rm with a script which would check to see if any element in the path
> is a symlink and if it is, to unlink the symlink itself.
>
> This would reduce the window, but not remove it.
>
> I suppose you could have the script do the above check and if it passes
> create a hardlink to the the file and then remove it, do the check again and
> then either unlink the hardlinked file or rename it back to the original and
> remove the bogus symlink.
>
> Ivan

This case definitively deserves a dedicated tool :) 

-- 
wave++ (also known, in some places, as "Yuri D'Elia") http://www.yuv.info/
The email address is fake (thanks swen)! You know how to contact me anyway.

Relevant Pages

  • Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
    ... the "open" syscall. ... forced unlink() followed by an open. ... copying to move across file systems and there is no way to control this. ... Changing the target to a symlink to a directory on a different file ...
    (FreeBSD-Security)
  • Re: fstat() and symlinks
    ... MR>> symlinks: unlink and readlink. ... MK> Also: rename() and lchown. ... There can be many of them, but they are explicitly designed to avoid symlink ...
    (comp.unix.programmer)
  • Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
    ... the "open" syscall. ... It only creates the temporary file if the target doesn't already exists, ... forced unlink() followed by an open. ... target file can be a symlink and openby default follows symlinks. ...
    (FreeBSD-Security)
  • RE: sym links
    ... It is not allowing me to "unlink" the symlink. ... I can try to wean them on to another ftp client, ...
    (freebsd-questions)