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
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 <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
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.
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 <[email protected]>
National Security Agency