>> personally, i *expect* those flags to make rm fail.  in the case that
>> they do so, rm prints an error, and then i can decide if i really
>> meant to remove that file (and remove the flags and try again if i
>> really really meant to remove the file).
>
>I noticed that, but I think it is okay. I would have been shocked if it
>tried to remove system immutable flags, but this is just about root
>ignoring user immutable flag, this is different.
>
>Root knows what (s)he is doing. If root decides to blow away some user
>data, I think that there should not be any way for the user to make it
>fail. Think about automatic /tmp cleanup for instance.

if automated /tmp cleanup is your concern, then you should already be
concerned about the mechanism as it stands.  it does a quick rm of
stuff that doesn't match a crude pattern and then tries to use find to
finish the job.  all i need to do to make stuff "stick" in /tmp is
name a directory lost+found or quota.user or quota.group; i don't need
any flags to do it.  the best way to clean tmp is with newfs or mount
an mfs on /tmp.  or not care at all about it (which is actually
easier).

>User immutable is for the user, so when a user uses rm, it should not
>remove user immutable files. But root should not care about user
>immutable flags. I see only one exception to this rule: I think it is
>bad to make rm remove user immutable flags on files owned by root.

i think we should sstick with the whole hog here.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."