Hi all,
A friend of mine just told me he could rm /proc/net/arp. Although I thought
he really needed to sleep, I tried it myself and was surprized to discover that
it was possible to change directory permissions in nearly all /proc subdirs,
but also remove many entries in /proc. There are two problems with this :
- I've found no way to make these entries appear again. Unmounting and
remounting has no effect.
- removing certain entries (or certain amount of entries) causes some
oopses (log attached).
This has been verified on kernel 2.2.14 and 2.2.17pre19. A quick turn-around would
be to remount /proc read-only after having set what you need in /proc/sys, but
that may hurt several configs.
I don't even understand why there's a "remove_proc_entry" function. Since the /proc
seems to stay coherent during a kernel's uptime, I suspect that nobody uses it
(except for rm -rf /proc/net/*, of course). Wouldn't it be better to simply replace
it with NULL in fs/proc/root.c ? I will quickly test this, but don't know what can
be the implications for now.
Hopefully it's not too late to fix it before final 2.2.17. Not tested it on 2.4 yet.
I'll recompile one kernel and post an obvious patch to remove remove_proc_entry()
soon if that seems to work. Anyway, it will still be possible to change the permissions
in the subdirectories. Perhaps this is desired behaviour ...
Later,
Willy
-- [shortened oops trace]remove_proc_entry: net/raw busy, count=1 de_put: deferred delete of raw proc_file_unlink: deleting ip_masq/app remove_proc_entry: ip_masq/app busy, count=1 de_put: deferred delete of app proc_file_unlink: deleting ip_masq/mfw remove_proc_entry: ip_masq/mfw busy, count=1 de_put: deferred delete of mfw kfree: Bad obj c027b280 Unable to handle kernel NULL pointer dereference at virtual address 00000000 current->tss.cr3 = 03c6d000, %cr3 = 03c6d000 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c0121d6a>] EFLAGS: 00010296 eax: 0000001b ebx: c027b280 ecx: 00000005 edx: 00000001 esi: c027b280 edi: c2dbac20 ebp: c380a000 esp: c3c35e0c ds: 0018 es: 0018 ss: 0018 Process rm (pid: 254, process nr: 9, stackpage=c3c35000) Stack: c029ad43 c029ad62 c027b280 c2d47ba0 c2dbac20 c380a000 00000000 c029ad62 c029ad43 c0114851 c027dcc0 c029ad62 c029ad62 c015047d c027b280 c2d47ba0 c2dbac20 c380a000 00000292 00000001 c029ad62 c014f1ff c027b280 c00bdc80 Call Trace: [<c0114851>] [<c015047d>] [<c014f1ff>] [<c014f1f6>] [<c0231ea0>] [<c0240444>] [<c01e6c9f>] [<c014f249>] [<c0114851>] [<c0114889>] [<c0132fcf>] [<c0150543>] [<c02320e0>] [<c0240444>] [<c0132001>] [<c014ffdd>] [<c014fff2>] [<c012d11d>] [<c012db1e>] [<c012f2dc>] [<c012dba5>] [<c012dbdb>] [<c010a0d2>] [<c010a0f4>] Code: c7 05 00 00 00 00 00 00 00 00 83 c4 10 5b 5e 5f 5d 83 c4 1c
>>EIP: c0121d6a <kfree+192/1a8> Trace: c0114851 <printk+121/168> Trace: c015047d <free_proc_entry+21/28> Trace: c014f1ff <de_put+57/60> Trace: c014f1f6 <de_put+4e/60> Trace: c0231ea0 <cprt+38c0/e700> Trace: c0240444 <timer_bug_msg+1424/b500> Trace: c01e6c9f <set_cursor+77/90> Trace: c014f249 <proc_delete_inode+2d/38> Trace: c014ffdd <proc_unlink+35/58> Trace: c010a0f4 <system_call+34/40> Code: c0121d6a <kfree+192/1a8> 00000000 <_EIP>: <=== Code: c0121d6a <kfree+192/1a8> 0: c7 05 00 00 00 00 00 movl $0x0,0x0 <=== Code: c0121d71 <kfree+199/1a8> 7: 00 00 00 Code: c0121d74 <kfree+19c/1a8> a: 83 c4 10 add $0x10,%esp Code: c0121d77 <kfree+19f/1a8> d: 5b pop %ebx Code: c0121d78 <kfree+1a0/1a8> e: 5e pop %esi Code: c0121d79 <kfree+1a1/1a8> f: 5f pop %edi Code: c0121d7a <kfree+1a2/1a8> 10: 5d pop %ebp Code: c0121d7b <kfree+1a3/1a8> 11: 83 c4 1c add $0x1c,%esp
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:10 EST