* idr_remove
@ 2005-02-19 12:32 Russell Coker
2005-02-22 17:35 ` idr_remove Lorenzo Hernández García-Hierro
2005-02-22 18:22 ` idr_remove Jim Houston
0 siblings, 2 replies; 4+ messages in thread
From: Russell Coker @ 2005-02-19 12:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Jim Houston
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
I am getting messages "idr_remove called for id=0 which is not allocated" when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case by installing a new kernel package on a SE Debian system. The
above URL references Jim Houston's message with the patch to add this
warning.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
[-- Attachment #2: log --]
[-- Type: text/plain, Size: 6489 bytes --]
Jan 17 13:45:43 lyta kernel: audit(1105929943.164:0): avc: denied { search } for pid=30322 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.347:0): avc: denied { search } for pid=30322 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.425:0): avc: denied { search } for pid=30328 exe=/usr/bin/stat name=run dev=dm-2 ino=597921 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:var_run_t tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.486:0): avc: denied { search } for pid=30328 exe=/usr/bin/stat name=run dev=dm-2 ino=597921 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:var_run_t tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.563:0): avc: denied { search } for pid=30333 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.713:0): avc: denied { search } for pid=30333 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:43 lyta kernel: audit(1105929943.785:0): avc: denied { search } for pid=30337 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:43 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:43 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:43 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:43 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:43 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:43 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:43 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:43 lyta kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75
Jan 17 13:45:43 lyta kernel: audit(1105929943.902:0): avc: denied { search } for pid=30337 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:44 lyta kernel: audit(1105929943.967:0): avc: denied { search } for pid=30341 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:44 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:44 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:44 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:44 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:44 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:44 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:44 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:44 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:44 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:44 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:44 lyta kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75
Jan 17 13:45:44 lyta kernel: audit(1105929944.072:0): avc: denied { search } for pid=30341 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:44 lyta kernel: audit(1105929944.150:0): avc: denied { search } for pid=30345 exe=/bin/bash name=/ dev=devpts ino=1 scontext=system_u:system_r:bootloader_t tcontext=system_u:object_r:devpts_t tclass=dir
Jan 17 13:45:44 lyta kernel: idr_remove called for id=0 which is not allocated.
Jan 17 13:45:44 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:44 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:44 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
Jan 17 13:45:44 lyta kernel: [release_dev+1636/1968] release_dev+0x664/0x7b0
Jan 17 13:45:44 lyta kernel: [tty_open+254/656] tty_open+0xfe/0x290
Jan 17 13:45:44 lyta kernel: [chrdev_open+258/496] chrdev_open+0x102/0x1f0
Jan 17 13:45:44 lyta kernel: [dentry_open+342/576] dentry_open+0x156/0x240
Jan 17 13:45:44 lyta kernel: [filp_open+77/80] filp_open+0x4d/0x50
Jan 17 13:45:44 lyta kernel: [sys_open+60/160] sys_open+0x3c/0xa0
Jan 17 13:45:44 lyta kernel: [sysenter_past_esp+82/117] sysenter_past_esp+0x52/0x75
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: idr_remove
2005-02-19 12:32 idr_remove Russell Coker
@ 2005-02-22 17:35 ` Lorenzo Hernández García-Hierro
2005-02-22 18:22 ` idr_remove Jim Houston
1 sibling, 0 replies; 4+ messages in thread
From: Lorenzo Hernández García-Hierro @ 2005-02-22 17:35 UTC (permalink / raw)
To: russell; +Cc: linux-kernel, Jim Houston, selinux
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
El sáb, 19-02-2005 a las 23:32 +1100, Russell Coker escribió:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
>
> I am getting messages "idr_remove called for id=0 which is not allocated" when
> SE Linux denies search access to /dev/pts.
>
> The attached file has some klogd output showing the situation, triggered in
> this case by installing a new kernel package on a SE Debian system. The
> above URL references Jim Houston's message with the patch to add this
> warning.
The problem seems to be in a call back from idr_remove() to
sub_remove()@/lib/idr.c:284 which leads to calling idr_remove_warning(),
doing the weird stack dump, when some logics don't work as expected.
Jan 17 13:45:43 lyta kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Jan 17 13:45:43 lyta kernel: [sub_remove+233/240] sub_remove+0xe9/0xf0
Jan 17 13:45:43 lyta kernel: [idr_remove+35/144] idr_remove+0x23/0x90
The spurious function called by sub_remove() (leads to the
dump_stack+0x17/0x20):
+static void idr_remove_warning(int id)
+{
+ printk("idr_remove called for id=%d which is not allocated.\n", id);
+ dump_stack();
+}
+
The changes that lead to such warning and stack dump
@sub_remove
+ n = id & IDR_MASK;
+ if (likely(p != NULL && test_bit(n, &p->bitmap))){
(...etc...)
idr_remove() is called, among other places, within the Device Mapper
(DM) code that I suppose you are using, right?
I don't have time to make further checking, but seems to be somewhat
type of devices handling and IDR minor numbers allocation tracking
black magic, someone could have a further a look at it?
Cheers,
--
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: idr_remove
2005-02-19 12:32 idr_remove Russell Coker
2005-02-22 17:35 ` idr_remove Lorenzo Hernández García-Hierro
@ 2005-02-22 18:22 ` Jim Houston
2005-02-22 18:32 ` idr_remove Stephen Smalley
1 sibling, 1 reply; 4+ messages in thread
From: Jim Houston @ 2005-02-22 18:22 UTC (permalink / raw)
To: russell; +Cc: linux-kernel
On Sat, 2005-02-19 at 07:32, Russell Coker wrote:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109838483518162&w=2
>
> I am getting messages "idr_remove called for id=0 which is not allocated" when
> SE Linux denies search access to /dev/pts.
>
> The attached file has some klogd output showing the situation, triggered in
> this case by installing a new kernel package on a SE Debian system. The
> above URL references Jim Houston's message with the patch to add this
> warning.
Hi Russell, Everyone,
I believe that the warning is correct. It is intended to catch
the case where an id is freed without being allocated. The most
likely case is the teardown of the pty is calling idr_remove()
twice for the same id value. The other possible case is that
an id has not been allocated and idr_remove() is being called
by mistake.
I spent time looking at the pty and selinux code yesterday.
I had little luck finding where the selinux code hooks into
the pty code.
I have not used selinux. I have a recent Fedora FC3 install but I
didn't enable selinux. If you can give me cookbook directions,
I will try to reproduce the problem here.
I was hoping that changing the file permissions on /dev/pts might
produce the same effect. It prevent xterm from opening the pty but
it didn't cause the idr_remove() warning.
Jim Houston - Concurrent Computer Corp.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: idr_remove
2005-02-22 18:22 ` idr_remove Jim Houston
@ 2005-02-22 18:32 ` Stephen Smalley
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Smalley @ 2005-02-22 18:32 UTC (permalink / raw)
To: Jim Houston; +Cc: russell, linux-kernel
On Tue, 2005-02-22 at 13:22 -0500, Jim Houston wrote:
> I spent time looking at the pty and selinux code yesterday.
> I had little luck finding where the selinux code hooks into
> the pty code.
The call to lookup_one_len() by fs/devpts/inode.c:get_node() ultimately
calls permission(...,MAY_EXEC,...) on the devpts root directory, which
will call security_inode_permission() -> selinux_inode_permission() to
check search access to the directory. Hence, get_node() can fail if
SELinux is enabled and the process has no permission at all to
search /dev/pts. If it can get that far, then the inode will ultimately
have its security label set upon the d_instantiate() call (via
security_d_instantiate() -> selinux_d_instantiate()), and be
subsequently checked for opens/reads/writes via the
selinux_inode_permission() and selinux_file_permission() hook functions.
--
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-02-22 18:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-02-19 12:32 idr_remove Russell Coker
2005-02-22 17:35 ` idr_remove Lorenzo Hernández García-Hierro
2005-02-22 18:22 ` idr_remove Jim Houston
2005-02-22 18:32 ` idr_remove Stephen Smalley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).