All versions so far of the second extended file system (ext2fs) as
implemented in the Linux kernel have the following security problem.

Any user is permitted to set any file attribute other than `immutable'
on files they own.  In particular, an unprivileged user can set the
`append-only' flag.  To do this merely requires the ability to execute
arbitrary code -- the flag is set by an ioctl(2) call.  The usual way
to set these flags is by use of the chattr(8) command.

The effects of the append-only flag being set on a file are

o No process, even with privileges, may open the file other than in
  append mode.  The file cannot be truncated.

o No process, even with privileges, may use link(2), unlink(2) or
  rename(2) on the file.

The flag can be set on a directory in the same way, in which case

o No process, even with privileges, may use rename(2) or rmdir(2) on
  the directory.

o No process, even with privileges, may use rename(2), rmdir(2) or
  unlink(2) on any entry in the directory.

The only differences between the effects of the append-only flag and
the immutable flag are that an append-only file may be appended to
(whereas an immutable file cannot be opened for writing at all), and an
append-only directory may have new entries added to it (whereas an
immutable directory can't be modified at all).  Note that the immutable
flag, because of its extensive effects, can only be set by a privileged
process, but the append-only attribute, with most of the same effects,
can be set by the owner of the file in question, even if unprivileged.

Obviously there are denial-of-service attacks based on this.  The most
obvious attack is to create a very large file in /tmp and make it
append-only -- any root-run program intended to clear /tmp will fail
unless it knows to remove the flag.  Even if it does know, there is a
race condition, as the flag cannot be cleared simultaneously with
deletion, but in this case much the same effect could be obtained by
merely keeping the file open.

Another possible use of this file attribute is to prevent a symbolic
link being removed, making some symlink-based attacks that rely on race
conditions work deterministically.  This is only possible if the
attacker owns the directory containing the symlink.

In general, anywhere a privileged process assumes it can remove or
rename a file owned by any user, that assumption is rendered incorrect
if the user can access the file to set the flag.

The only possible solution is to modify the semantics of the
append-only attribute in the kernel.  There are three likely
approaches: (1) setting the append-only flag can be limited to
privileged processes; (2) the linking-related effects of the flag can
be removed, bringing it in line with the description in the chattr man
page; (3) the effects of the flag could be made to have no effect on
privileged processes.  (3) opens some security holes itself, but should
be borne in mind.  I produced a patch implementing (2) some time ago,
but it the relevant kernel developers say that (1) is the preferred
approach.