Subject: kern/32449: chflags won't unset schg, heh
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <netbsdMLpostNO@SPAM.quake.ca>
List: netbsd-bugs
Date: 01/04/2006 03:15:00
>Number:         32449
>Category:       kern
>Synopsis:       chflags won't unset schg
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 04 03:15:00 +0000 2006
>Originator:     Marc Tooley
>Release:        NetBSD 3.99.15
>Organization:
>Environment:
System: NetBSD warp.sudog.com 3.99.15 NetBSD 3.99.15 (warp) #2: Mon Jan 2 11:57:09 PST 2006 root@warp.sudog.com:/usr/src-current/sys/arch/i386/compile/warp i386
Architecture: i386
Machine: i386
>Description:
	Setting schg on files works. Unsetting it doesn't appear to.
	Calling the system call directly doesn't even seem to fix the issue,
	so updating userland probably won't make a difference.
>How-To-Repeat:
	:warp:01:01:40 ~# touch test
	:warp:01:01:49 ~# chflags noschg test
	:warp:01:01:50 ~# ls -liao test
	179243 -rw-r--r--  1 root  wheel  - 0 Jan  3 01:01 test
	:warp:01:01:56 ~# chflags schg test
	:warp:01:01:58 ~# ls -liao test
	179243 -rw-r--r--  1 root  wheel  schg 0 Jan  3 01:01 test
	:warp:01:02:00 ~# chflags noschg test
	chflags: test: Operation not permitted
	
	As a test, I believe the following assembly program calls the syscall
	directly:

	section .note.netbsd.ident progbits alloc noexec nowrite
		dd	0x00000007
		dd 0x00000004
		dd 0x00000001
		db	0x4e,0x65,0x74,0x42,0x53,0x44,0x00,0x00
		db 0xe1,0x0c,0x03,0x00
		dd 0x00000007
		dd 0x00000007
		dd 0x00000002
		db 0x4e,0x65,0x74,0x42,0x53,0x44,0x00,0x00

	section .data
		msg	db	"test",0x0
		len	equ $-msg

	section .text
		global _start
	_start:
		push 	dword msg
		push	dword 0x00 ; blank flags setting.
		mov	eax,0x22 ; chflags syscall is 34 or 0x22
		int	0x80
	myret:
		mov	eax,0x1 ; syscall #1 is exit
		int	0x80

	Build with nasm:

	nasm -f elf file.s
	ld -s -o file file.o

>Fix:
	Not a clue. I traced chflags() back to sys/kern/vfs_syscalls.c but I just
	don't have the expertise to step through these kernel system calls (yet.)

	There has been a great deal of activity going on in that file recently 
	though..