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..