Messages in this thread |  | | From | Willy Tarreau <> | Date | Thu, 24 Aug 2000 00:59:44 +0200 (CEST) |
| |
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/
|  |