lkml.org 
[lkml]   [2002]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ext3 and undeletion
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:0.030 / U:1.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site