>Arthur D. Jerijian writes:
[...]
>-> * Perhaps, incorporate ext2fs encryption and/or file undeletion.
>->
> Undelete should be done in userspace. There's absolutely NO good
>reason to do it in kernel space, and in addition, userspace undelete
Umm, over the last few weeks we've had an entire thread on the
disadvantages of userspace undelete - perhaps you could elaborate on
_why_ you think the reasons given (some by myself) in that thread were
not "good".
>schemes support all filesystems for free! If you're really interested
>in undelete, take a look at the entomb package from Purdue
>(ftp://ftp.cc.purdue.edu/pucc/entomb-3.5.tar.gz). It consists of a
[...]
Got it. Refuses to compile on Linux (tries to replace some functions
which are in fact macros in Linux, also some files seem to be missing)
so my comments are based on looking at the source and docs:
- requires recompiling all programs such as mv,cp,rm with new library.
- could perhaps make a shared library and use LD_PRELOAD - still
requires recompiling static binaries and setuid programs may remove
LD_* for security reasons. Also I'm not sure libtomb is clean enough
for such widespread use - eg. see the comments on SIGCHLD.
- because it's in user space it has to use ownership changes to get
round problems like quotas, leading to:
- has to fork and exec a setuid root program for _every_ deletion.
- loss of permission info on entombed files.
- copying files on deletion (deletion may increase fs usage!)
- wont work on non-unix filesystems (causes problems even on NFS).
- because it's in user space it has to do some ugly (and slow) looking
hacks to find the "tomb" on the same filesystem as the file, remember
it has to do this _every_ time it deletes a file...
- because it's in user space there is no way for the tomb manager
daemon to purge files whenever the fs needs space - you have to rely
on running it every few minutes and hoping the fs doesn't fill up in
between. The purging policies are inflexible - _all_ entombed files
are deleted if fs fills up, so if I had eg. 74% deleted files, 25%
real files and created some more... _all_ the deleted files go.
- no information stored about deleted directories (or what directories
files are deleted from).
...I could probably go on. Note that the authors realise this:
"...we recognize that the most comprehensive method of solving
this problem is to do so at the kernel level..."
Note also that on commercial unixen userspace is the *only* option
(unless vendor provides solution). On Linux we can do it right.
Above you say:
>userspace undelete schemes support all filesystems for free!
Sorry, I disagree. It may appear that way at first, but you soon find
the implementation assuming things about the filesystem which may not
be true, considering entomb again...
- because quotas may cause problems on some filesystems entomb changes
ownership of deleted files - thus immediately restricting it's use to
filesystems which support unix UID/GIDs and chown(). Forget MSDOS,
vfat, isofs, hfs, hpfs, smbfs, ncpfs, etc., and expect problems on NFS.
- because of the limitations of userspace entomb sometimes uses link()
and unlink() or copy() instead of rename(), to move files to the
tomb. Using link() on every deleted file will cause horrible problems
on (for example) umsdos because of the limitations of the fs
implementation of link().
- it's use on network file systems is limited - I think undelete
should always be implemented on the server, but a userspace solution
is running on the client. Some file servers already have (better)
undelete implementations (eg. Netware), a vfs/fs level solution could
support these in a uniform manner, which entomb can't.
- entomb relies on creating a subdirectory in the tomb for each uid.
Some fs's cannot do this, eg. ext2 - 64k uids, max subdirs < 32k.
- because entomb doesn't know about the details of the fs it can break
some of them. The ext2 undelete attribute is ignored. Copying deleted
files will lose their ext2 extended attributes (and acls too when they
exist). In fact such copying will *BREAK* any ext2 implementation of
the secure deletion attribute.
Finally (and this ones a beauty):
- entomb relies on creating a unique name for each tombed file by
appending a decimal timestamp (9,10 chars ?). It loops until it gets a
unique name this way. Thus it requires <filename><timestamp> to be a
legal file name for any legal <filename>.
I don't think this is true on *ANY* Linux filesystem. Moreover, since
some Linux fs's truncate over-long names entomb may loop forever.
Many of the above problems are caused IMO by the constraints of
working from userspace. Compare with a filesystem implementation like
Netware.
ray
--
Ray Auchterlounie Research Student (still) at:
<rda@kythera.demon.co.uk> Signal Processing Group
<rda@eng.cam.ac.uk> Cambridge University Engineering Dept.
"Don't ask me about my thesis (TM)"