kern/122047: incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others)

[Ighighi]

>Number:         122047
>Category:       kern
>Synopsis:       incorrect handling of UF_IMMUTABLE / UF_APPEND flag on EXT2FS (maybe others)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 24 13:10:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Ighighi
>Release:        6.3-STABLE
>Organization:
>Environment:
FreeBSD orion 6.3-STABLE FreeBSD 6.3-STABLE #0: Fri Mar 21 15:20:50 VET 2008     root at orion:/usr/obj/usr/src/sys/CUSTOM  i386
>Description:
On EXT2 filesystems (and maybe others), the kernels seems to handle UF_IMMUTABLE
and SF_IMMUTABLE separately only until they're unmounted. When these filesystems
are mounted afterwards, both flags are set. This of course happens because 
EXT2FS has only one immutable bit.

So it is now a question of policy:
How should we map UF_IMMUTABLE & SF_IMMUTABLE to EXT2_IMMUTABLE_FL ?

The problem is that users may set any of the UF_* flags.  If any of these is 
later made SF_ too, those UF_* flags would be useless (and inconvenient) for the
user because suddenly they can't turn them off and work on files they own...
So being those flags usable by root alone, we must ask this question:
Are they useful to the superuser or they are not ?  If they are not, then 
dropping support for append/immutable flags for EXT2FS makes sense. If they are,
we shouldn't allow normal users to set those SF_* flags in this indirect way.

In this case, the issue of policy is better left on the administrator to choose
from, as it's done in the UNIX world ;)

I found this kernel option in NetBSD in options(5):
     options EXT2FS_SYSTEM_FLAGS
     This option changes the behavior of the APPEND and IMMUTABLE flags for a
     file on an EXT2FS file system.  Without this option, the superuser or
     owner of the file can set and clear them.	With this option, only the
     superuser can set them, and they can't be cleared if the securelevel is
     greater than 0.  See also chflags(1).

I believe it'd be best on a per-filesystem basis as a mount() option anyway and
to ignore the SF_* flags on filesystems mounted by normal users by default.

FWIW, I think this PR may apply to REISERFS and DragonFly.
>How-To-Repeat:
As root, run:

# /bin/dd if=/dev/zero of=/tmp/ext2fs.img bs=1k count=1024
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.042202 secs (24846597 bytes/sec)                      
# device=$(/sbin/mdconfig -f /tmp/ext2fs.img)
# /usr/local/sbin/mke2fs /dev/$device
# /bin/mkdir /tmp/ext2fs.mnt
# /sbin/mount_ext2fs /dev/$device /tmp/ext2fs.mnt
# /bin/mkdir -m 1777 /tmp/ext2fs.mnt/tmp                                      

Then, on a user account:

$ touch /tmp/ext2fs.mnt/tmp/foobar
$ /bin/ls -lo /tmp/ext2fs.mnt/tmp/foobar
-rw-r--r--  1 ighighi  wheel  - 0 Mar 24 06:57 /tmp/ext2fs.mnt/tmp/foobar            
$ /bin/chflags uchg /tmp/ext2fs.mnt/tmp/foobar
$ /bin/ls -lo /tmp/ext2fs.mnt/tmp/foobar
-rw-r--r--  1 ighighi  wheel  uchg 0 Mar 24 06:57 /tmp/ext2fs.mnt/tmp/foobar
$ /bin/chflags nouchg /tmp/ext2fs.mnt/tmp/foobar
$ ls -l /tmp/ext2fs.mnt/tmp/foobar
-rw-r--r--  1 ighighi  wheel  - 0 Mar 24 06:57 /tmp/ext2fs.mnt/tmp/foobar            
$ /bin/chflags uchg /tmp/ext2fs.mnt/tmp/foobar

Then, as root, run:

# /sbin/umount -v /tmp/ext2fs.mnt
/dev/md0: unmount from /var/tmp/ext2fs.mnt                                           
# /sbin/mount_ext2fs /dev/$device /tmp/ext2fs.mnt                                                 

Now, as the user, run:

$ /bin/ls -lo /tmp/ext2fs.mnt/tmp/foobar
-rw-r--r--  1 ighighi  wheel  schg,uchg 0 Mar 24 06:57 tmp/ext2fs.mnt/tmp/foobar    
$ /bin/chflags nouchg /tmp/ext2fs.mnt/tmp/foobar
chflags: /tmp/ext2fs.mnt/tmp/foobar: Operation not permitted                         


>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: