From owner-freebsd-hackers  Fri Nov  1 19:22:00 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA12048
          for hackers-outgoing; Fri, 1 Nov 1996 19:22:00 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA12024;
          Fri, 1 Nov 1996 19:21:45 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id OAA11890; Sat, 2 Nov 1996 14:17:46 +1100
Date: Sat, 2 Nov 1996 14:17:46 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199611020317.OAA11890@godzilla.zeta.org.au>
To: freebsd-hackers@freebsd.org, taob@io.org
Subject: Re: Effect of UF_APPEND/SF_APPEND on file modes
Cc: ache@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>    Shouldn't I be able to chown/chmod a file with the UF_APPEND or
>SF_APPEND flag set?  I'm getting EPERM on those operations.

Don't know.  It seems reasonable to allow it, but *APPEND is generally
grouped with *IMMUTABLE in the permissions checks, and it is for all
attribute changes - things like `touch' also fail.

>I can
>delete the file just fine.

This seems to be a bugfeature in /bin/rm.  unlink(2) fails correctly.
/bin/rm seems to attempt to handle the UF_APPEND and UF_IMMUTABLE
flags in the the same way for root (by silently blowing them away),
but it actually handles them diferrently because access(2) fails for
the uchg case so the special handling of UF_IMMUTABLE doesn't get used.

Bruce