>> For proof of this, create a file in /tmp, set the schg flag and try
>> remove the file.  Try rebooting, and see what happens when something
>> tries to remove it whilst cleaning /tmp on reboot.
   
>>       142: touch /tmp/foo
>>       143: chflags uchg /tmp/foo
>>       144: rm -f /tmp/foo
>>       rm: /tmp/foo: Operation not permitted
>>       145: mv -f /tmp/foo /tmp/bar
>>       mv: rename /tmp/foo to /tmp/bar: Operation not permitted
>>       146: touch /tmp/xx
>>       147: mv -f /tmp/xx /tmp/foo
>>       mv: rename /tmp/xx to /tmp/foo: Operation not permitted
>>   
>>   So far so good.  But....
>>   
>>       148: chflags nouchg /tmp/foo
>>       149: rm /tmp/foo
>>       150: ls /tmp/foo
>>       ls: /tmp/foo: No such file or directory
>>   
>>   I didn't try the super-user version so may be this hole is filled.
>>   [Besides, it does say this call is under development:-)]
>>   
>>   Any way, I have said what I wanted to on this topic so I
>>   will shut up now.
> 
> what was your securelevel for this ?  if it was > 0, then this is
> a security bug that should have been fixed a long time ago.

from CHFLAGS(2)             NetBSD Programmer's Manual             CHFLAGS(2)

     The ``UF_IMMUTABLE'' and ``UF_APPEND'' flags may be set or unset by ei-
     ther the owner of a file or the super-user.

     The ``SF_IMMUTABLE'' and ``SF_APPEND'' flags may only be set or unset by
     the super-user.  They may be set at any time, but normally may only be
     unset when the system is in single-user mode.  (See init(8) for details.)