linux-kernel - mode_t: linux/types.h vs. glibc's sys/types.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <200708231412.11752.jzb2@aexorsyst.com>
Date:	Thu, 23 Aug 2007 14:12:11 -0700
From:	"John Z. Bohach" <jzb2@...orsyst.com>
To:	linux-kernel@...r.kernel.org
Subject: mode_t:  linux/types.h vs. glibc's sys/types.h

Howdy,

I've tried googling for this, and searched the archives as well, but I 
haven't found a satisfactory answer.  My apologies if this is covered 
somewhere...

The kernel's linux/types.h resolves mode_t to __kernel_mode_t which is 
then defined as:

typedef unsigned short  __kernel_mode_t;

in linux/posix_types.h.

However, glibc's sys/types.h eventually (in bits/typesizes.h) resolves 
mode_t to:

#define __MODE_T_TYPE           __U32_TYPE

So, when I try to pass a mode_t type from kernel space to user space, 
the kernel sends a short when the user space expects an int.  I of 
course declare my variable as 'mode_t' both in my kernel module and in 
my user-space app., with the above inconsistency.

I can get around this easily enough by sending/receiving __u32, but I'm 
trying to be a little more type-safe...

Is this something that is intentional, or is this an inconsistency 
between linux and glibc?  I've verified this both on 2.6.16.47 and 
2.6.20.6.  Any ideas?

Thanks,
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/