James D Strandboge wrote:
>On Tue, Feb 26, 2002 at 11:48:49AM -0600 or thereabouts, Rose, Billy wrote:
>
>It seems to me the undelete could be in the kernel, and could be
>beneficial.
>
>Rather than modifying all the different filesystems, or libc, we could
>modify the VFS unlink function in the kernel. It would therefore work
>with all filesystems working under VFS, and all programs regardless of
>whether it is linked against the latest libc or using LD_PRELOAD.
>
>There are obviously some issues that would have to be resolved with the
>algorithm, but as far as versioning I think that is the role of backups.
>This should be more along the lines of 'whoops I deleted /etc/fstab.
>Let me go get it out of /.undelete'. Simply put, if the file is already
>in there, just overwrite it. Though, it wouldn't be too hard to tack a
>.1 on the end of the old file I suppose.
>
>Also, if the files are just moved to the .undelete directory (and by
>moved, I mean a hard link to .undelete, followed by a remove of the
>original), disk usage as reported by df and du would still show it
>as there. I don't think that is a very big deal. I simple solution
>would just be to have a cron job empty out older files. It should be the
>sysadmin's job on how to manage the .undelete directory, not the kernel's
>(IMO). Of course, a configurable daemon to monitor the directory could
>be implemented, but this especially seems like a userspace problem.
>
>Undeleting is the harder of these. User's should be able to undelete a
>file IMO. Either an suid binary has to be created to list the contents
>of the .undelete directory based on the user running it, or they can go
>into the directory and get what they need. Rather than having a world
>write /tmp like directory, it could be chmod 1755 with root ownership.
>That way users could browse the directory and cp out what they wanted,
>but they can't write to it and overwrite files and do symlink attacks,
>etc. This is a security issue in terms of privacy though, depending on
>the user's umask. The former (an suid binary) is probably better, but
>the latter is the easier to implement.
>
>Please comment.
>
>James Strandboge
>
My 2ctvs.
An example:
We have a file server with these fs mounted in /mnt
/
+-mnt
| +-fs1
| | +-dir1
| | | +--rw-r--r-- 1 root root 121 dic 13 19:47
file1.txt
| | | +--rw-r--r-- 1 paul sales 232121 dic 13 19:47
file2.txt
| | +-dir2
| | | +--rw-r--r-- 1 root root 72534 dic 14 20:27
file1.txt
| | | +--rw-r--r-- 1 mary sales 9493 dic 14 20:27
file2.txt
| +-fs2
| | +-dir1
| | | +--rw-r--r-- 1 root root 2312 dic 13 19:55
other1.txt
| | | +--rw-r--r-- 1 root root 232 dic 13 19:55
other2.txt
| | +-dir2
| | +--rw-r--r-- 1 root root 2534 dic 14 20:34
file1.txt
| | +--rw-r--r-- 1 root root 493 dic 14 20:54
file2.txt
|
.
Then, UserA delete /mnt/fs1/dir1/file2.txt and UserB delete
/mnt/fs1/dir2/file2.txt and create a new one. The state of the file
server will be:
+-mnt
| +-fs1
| | +-dir1
| | | +--rw-r--r-- 1 root root 121 dic 13 19:47
file1.txt
| | +-dir2
| | | +--rw-r--r-- 1 root root 72534 dic 14 20:27
file1.txt
| | | +--rw-r--r-- 1 UserB sales 9493 Mar 02 12:22
file2.txt
| | +-.undelete
| | +--rw-r--r-- 1 paul sales 232121 dic 13 19:47
+2001-12-13 19:47:23+dir1+file2.txt
| | +--rw-r--r-- 1 mary sales 9493 dic 14 20:27
+2001-12-14 20:27:44+dir2+file2.txt
| +-fs2
| | +-dir1
| | | +--rw-r--r-- 1 root root 2312 dic 13 19:55
other1.txt
| | | +--rw-r--r-- 1 root root 232 dic 13 19:55
other2.txt
| | +-dir2
| | +--rw-r--r-- 1 root root 2534 dic 14 20:34
file1.txt
| | +--rw-r--r-- 1 root root 493 dic 14 20:54
file2.txt
|
.
I mean:
When a user delete a file, the old version would be moved to .undelete
directory and renamed:
yyyy-MM-dd hh:mm:ss+directory+from+became+filename.ext
and there would be a '.undelete' directory inside each mounted fs (with
undelete option in /etc/fstab?).
In this way we can undelete erased files AND complete directory erases.
The date/time attr of the files in 'undelete' directory could be set the
delete time.
The rwx attr do not change
Another filename version could be:
yyyy-MM-dd
hh:mm:ss+owner_user+owner_group+rwxrwxrwx+directory+from+became+filename.ext
The date/time attr of the files in 'undelete' directory would have the
delete time AND the uid/gid would have the uid/gid of the user that
delete the files, so he/she will have rights to undelete it.
The rwx attr changes to 440 I think...
If the fs does not support long names, then we could to move and rename
it as file1.txt.1, file1.txt2, etc...
A undelete utility that complete the picture would be usefull.
Sorry my English. ;-)
Pablo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:24 EST