Date: Sun, 5 Jul 1998 04:51:20 -0300 (EST) From: Joao Carlos Mendes Luis <jonny@jonny.eng.br> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/7169: accton on a append-only file Message-ID: <199807050751.EAA03831@roma.coe.ufrj.br>
next in thread | raw e-mail | index | archive | help
>Number: 7169
>Category: kern
>Synopsis: cannot use accton on a append-only file
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Jul 5 00:50:00 PDT 1998
>Last-Modified:
>Originator: Joao Carlos Mendes Luis
>Organization:
COPPE/UFRJ
>Release: FreeBSD 2.2.6-STABLE i386
>Environment:
FreeBSD-stable (but bug is probably present in -current also)
>Description:
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.
>How-To-Repeat:
$ chflags sappend /var/account/acct
$ accton /var/account/acct
>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.
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807050751.EAA03831>