I want to raise the security of my system, making heavy use of
	securelevel and file flags.  All log files should be append-only,
	ie, flagged sappend.  This worked for most files, but not for
	accounting files (accton).  acct(2) is returning EPERM for an
	append-only file as argument.

Fix: 

I don't have enough knowledge to fix, but the bug seems to
	be in the kern_acct.c file.  I've sent a message about this
	to -hackers list, and received this answer.

...
Message-Id: <199807041545.RAA13938@semyam.dinoco.de>
cc: Joao Carlos Mendes Luis <jonny@jonny.eng.br>, seggers@semyam.dinoco.de
To: hackers@FreeBSD.ORG
Subject: Re: accton on a append-only file ? 
Date: Sat, 04 Jul 1998 17:45:36 +0200
From: Stefan Eggers <seggers@semyam.dinoco.de>

> I've created the /var/account/acct file with sappend,sunlink flags,
> but accton return EPERM.  If I run accton before setting those flags,

>   This seems to be a bug, but I still have much to learn from VFS

To me, too.  It is because kern_acct.c in 2.2-stable opens the file
for writing, not for appending.  There is the problem:

        /*
         * If accounting is to be started to a file, open that file for
         * writing and make sure it's a 'normal'.
         */
        if (uap->path != NULL) {
                NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_USERSPACE, uap->path, p);
                error = vn_open(&nd, FWRITE, 0);
                if (error)
                        return (error);


Unless there is already a PR for this (check the PR database on the
FreeBSD web pages) I'd suggest sending in a new one.

> before searching for the culprit myself.  Does it deserve a send-pr,
> even without patches ?

I think it's as easy as adding FAPPEND to the mode.  The only problem
is making sure that it has no unexpected side effects.  If you like
quote this email in the PR to point at a possible way to fix it.

Stefan.
-- 
Stefan Eggers                 Lu4 yao2 zhi1 ma3 li4,
Max-Slevogt-Str. 1            ri4 jiu3 jian4 ren2 xin1.
51109 Koeln
Federal Republic of Germany

...

	Taking a quick look at ufs_vnops.c, it really seems that
	a FWRITE|O_APPEND in the vnopen() call will fix, but again
	I'm not aware of possible problems.  I've tested it at home,
	and it worked, but it would be much better if it was revised
	by a real FS hacker.
How-To-Repeat: 
	$ chflags sappend /var/account/acct
	$ accton /var/account/acct