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

    --
    Email: jstrand1@rochester.rr.com
    GPG/PGP ID: 26384A3A
    Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
    -
    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.024 / U:151.968 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site