Re: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

Re: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Petr Vandrovec]

On 14 May 01 at 15:00, Khachaturov, Vassilii wrote:

> I had to communicate uid/gid from an application down 
> to a driver, and discovered that uid and gid in user
> space are different from those in kernel space.

ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
'long' type for uid/gid. Unfortunately it still needs conversions
on some archs, so maybe using u_int64_t is just best solution
(AFAIK as MIPS unsigned long is 64bit, you have to use u_int64_t
if you want same type accross architectures).

Kernel part then just checks wheter uid == (__kernel_uid_t)uid and 
gives up if they differ.
                                    Best regards,
                                        Petr Vandrovec
                                        vandrove@vc.cvut.cz

Re: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Ralf Baechle]

On Mon, May 14, 2001 at 09:14:26PM +0000, Petr Vandrovec wrote:

> > I had to communicate uid/gid from an application down 
> > to a driver, and discovered that uid and gid in user
> > space are different from those in kernel space.
> 
> ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
> 'long' type for uid/gid. Unfortunately it still needs conversions
> on some archs, so maybe using u_int64_t is just best solution
> (AFAIK as MIPS unsigned long is 64bit, you have to use u_int64_t
> if you want same type accross architectures).

Only for the 64 bit ABI and kernel on MIPS have a long data type of 64 bits.
General rule for Linux sizeof(pointer) = sizeof(long).

> Kernel part then just checks wheter uid == (__kernel_uid_t)uid and 
> gives up if they differ.

Otherwise funny ones line (u16) 65536 == 0 -> root access could happen ...

  Ralf

RE: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Chris Wing]

Vassilii:

> I am trying to understand what's the cleanest coding that would allow
> 1) user code to just use uid/gid for interfacing the driver control
> structures
> 2) driver code to read/write the corresponding structure fields with minimum
> awareness of the actual difference between kernel and user uid_t/gid_t
> layout.

Just define a structure like:

struct user-to-kernel {
	unsigned int	uid;
	unsigned int	gid;
	...
}

and copy the header into your user space program. The alignments may
differ between different Linux architectures, but that won't matter.
You aren't going to be running a program compiled on a sparc on an i386
anyway...

If you are writing a filesystem or sending data over the network directly
via the kernel (without going through the user space program), then you
will need to decide upon a fixed byte order and alignment. (but this
doesn't seem to be the case for you, right?)

-Chris
wingc@engin.umich.edu

RE: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Khachaturov, Vassilii]

Chris,
thanks for your reply.

My case is exactly when copying has to be made, hence the awareness
of the user/kernel uid/gid "personalities".

I am trying to understand what's the cleanest coding that would allow
1) user code to just use uid/gid for interfacing the driver control
structures
2) driver code to read/write the corresponding structure fields with minimum
awareness of the actual difference between kernel and user uid_t/gid_t
layout.
3) all the messy adaptation confined as much as possible at the types
declaration (in the header included by both)
4) (2) & (3) should take into acct different platforms.

Right now, I allocate a uid_t/gid_t in the corresponding structure field
at the user level, and add arch-dependent padding in the kernel; and I had
to wrap the kernel-level access to these fields with special encoder/decoder
macros as long as user<->kernel interaction is taking place :-(
- see my orig. post for details.

My driver code doesn't use the __kernel types directly, but in the wrapping 
header macros I preferred those because I was explicitly defining the
padding logic, 
and was treating difference betw. user and kernel-level uids and gids.

V.
-----Original Message-----
From: Chris Wing [mailto:wingc@engin.umich.edu]

Vassilii:

__kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t
are NOT supposed to be different in kernel and user space.

[snip]

Kernel code should always use uid_t as a type, except when copying data
between user and kernel space. In that case, just make sure that whatever
data structure you use is big enough to contain a Linux uid_t. (as of 2.4,
Linux uses 32-bit uid_t on all platforms) All new interfaces to user space
should use 32-bit uids, i.e. type unsigned int.

Don't use __kernel_uid_t at all in new code. The name is basically there
only because the older libc5 C library included the kernel headers and we
have to preserve it so that programs still compile on these old systems.

if you look inside /include/linux/types.h, this is made explicit:

#ifdef __KERNEL__
typedef __kernel_uid32_t	uid_t;

[snip]

Re: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Chris Wing]

Vassilii:

__kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t
are NOT supposed to be different in kernel and user space.

They used to differ, and the junk in /include/linux/highuid.h is there to
handle all old programs which used the smaller (16-bit) uid_t.

Kernel code should always use uid_t as a type, except when copying data
between user and kernel space. In that case, just make sure that whatever
data structure you use is big enough to contain a Linux uid_t. (as of 2.4,
Linux uses 32-bit uid_t on all platforms) All new interfaces to user space
should use 32-bit uids, i.e. type unsigned int.

Don't use __kernel_uid_t at all in new code. The name is basically there
only because the older libc5 C library included the kernel headers and we
have to preserve it so that programs still compile on these old systems.

if you look inside /include/linux/types.h, this is made explicit:

#ifdef __KERNEL__
typedef __kernel_uid32_t	uid_t;
typedef __kernel_gid32_t	gid_t;
...
...


Thanks,

Chris Wing
wingc@engin.umich.edu

uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Khachaturov, Vassilii]

I had to communicate uid/gid from an application down 
to a driver, and discovered that uid and gid in user
space are different from those in kernel space.

I am porting both the driver and the app from platforms
where uid and gid in userland don't differ from their
counterparts down in the kernel.

What would be the appealing portable way (across all 
Linux platforms with their different byteorders) to 
declare a type for such user/kernel interface?

Right now I am using smth that I feel is ugly a bit, 
to declare fields of a transparent type:
/* MY uid_t/gid_t - shared types for user and kernel space */ 
   #if defined(LINUX) && defined (__KERNEL__) 
    
   #ifdef CONFIG_X86 
    
   #       define my_uid_t(var_name,pad_name) \ 
                   __kernel_uid_t var_name; unsigned short pad_name 
   #       define my_gid_t(var_name,pad_name) \ 
                   __kernel_gid_t var_name; unsigned short pad_name 
   #else /* other archs I need to support, with arch-specific alignment */
...
   #endif 
    
   #else /* Not Linux kernel - uid/gid same in user/kernel space */ 
   #       define my_uid_t(var_name,pad_name) uid_t var_name 
   #       define my_gid_t(var_name,pad_name) gid_t var_name 
   #endif 

and also I need special functions to set/get the var+
padding in kernel to make sure that the padding is set 
to 0/-1 according to the sign of the var, each time I get
smth from/send smth to the userland from the kernel.

Is there a known pattern for doing things like this? 
Maybe some special macros just for gid/uid specifically? I am 
just feeling that I try reinvent a wheel here...

Kind regards,
	Vassilii