lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: EXT2_UNRM_FL
unknown@riverstyx.net writes:
> On Thu, 4 Mar 1999, Richard Gooch wrote:
>
> > > > (d) why not do it in userspace anyway? I did that years ago, although
> > > > I "moved" files to /tmp, but it would be easy enough to move to a
> > > > garbage/$LOGNAME directory on the same FS.
> > > >
> > > > Absolutely, agreed. As I said earlier, there are plenty of user-space
> > > > "rm" replacements, and doing it in the kernel is almost certainly not
> > > > worth the pain.
> > > >
> > > > It might be worth it for the kernel to add a wakeup to the undelete
> > > > daemon telling it that space is low and it should remove some of the
> > > > deleted files, but I'd want to see how well a strategy of polling every
> > > > minute works (or doesn't work) before deciding whether the extra kernel
> > > > bloat was worth it.
> > > >
> > > one thing I am concerned is the those 'rm' replacements does not cover all
> > > the cases. For example, you can call 'unlink' directly from c/perl
> > > program, which will not go through 'rm'. If you really want undelete
> > > freature, I think it should be done a little higher level than, replacing
> > > 'rm'. hrmm that makes me wonder.. when you overwrite a file, does the
> > > kernel 'unlink' the file first and assign a new inode?
> >
> > OK, so do it in the C library, or write a wrapper for unlink(3) and
> > use LD_PRELOAD and override that way. That just leaves old statically
> > linked binaries. I don't consider this feature to be sufficiently
> > critical such that old static binaries need it.
> >
> > You can overwrite an existing file. The same inode is used.
>
> If it's at all a security concern, then it's a pretty big concern.
> Anyone can find a way of getting their own statically linked
> binaries. I don't think doing it in the C library would be that
> great an idea... or that useful an idea for that matter. Adding
> some conditional code into vfs_unlink() in fs/namei.c would be great
> 'coz that's the multiplexer for the various filesystems' unlink
> code. It'd also make it pretty easy to turn off. You could even
> throw in a file into proc to turn it on and off. That'd be the bomb
> -- I'd turn it before alcohol, turn it back off when I'm sober :-)
> If I remembered, that is...

What "security concern" are you talking about? Someone asked a
question about how copying to a file works, and I answered that. It
was separate to the discussion, though, and has nothing to do with
security.

Note that static binaries don't matter. They will just exhibit the
existing behaviour (delete). No security problem there.

There is simply no need for an undelete/move-to-garbage-area feature
in the kernel. It can all be done perfectly fine in userspace.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:1.753 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site