1 ============================================== 1 ===================================================
2 Notes on the change from 16-bit UIDs to 32-bit 2 Notes on the change from 16-bit UIDs to 32-bit UIDs
3 ============================================== 3 ===================================================
4 4
5 :Author: Chris Wing <wingc@umich.edu> 5 :Author: Chris Wing <wingc@umich.edu>
6 :Last updated: January 11, 2000 6 :Last updated: January 11, 2000
7 7
8 - kernel code MUST take into account __kernel_ 8 - kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
9 when communicating between user and kernel s 9 when communicating between user and kernel space in an ioctl or data
10 structure. 10 structure.
11 11
12 - kernel code should use uid_t and gid_t in ke 12 - kernel code should use uid_t and gid_t in kernel-private structures and
13 code. 13 code.
14 14
15 What's left to be done for 32-bit UIDs on all 15 What's left to be done for 32-bit UIDs on all Linux architectures:
16 16
17 - Disk quotas have an interesting limitation t 17 - Disk quotas have an interesting limitation that is not related to the
18 maximum UID/GID. They are limited by the max 18 maximum UID/GID. They are limited by the maximum file size on the
19 underlying filesystem, because quota records 19 underlying filesystem, because quota records are written at offsets
20 corresponding to the UID in question. 20 corresponding to the UID in question.
21 Further investigation is needed to see if th 21 Further investigation is needed to see if the quota system can cope
22 properly with huge UIDs. If it can deal with 22 properly with huge UIDs. If it can deal with 64-bit file offsets on all
23 architectures, this should not be a problem. 23 architectures, this should not be a problem.
24 24
25 - Decide whether or not to keep backwards comp 25 - Decide whether or not to keep backwards compatibility with the system
26 accounting file, or if we should break it as 26 accounting file, or if we should break it as the comments suggest
27 (currently, the old 16-bit UID and GID are s 27 (currently, the old 16-bit UID and GID are still written to disk, and
28 part of the former pad space is used to stor 28 part of the former pad space is used to store separate 32-bit UID and
29 GID) 29 GID)
30 30
31 - Need to validate that OS emulation calls the 31 - Need to validate that OS emulation calls the 16-bit UID
32 compatibility syscalls, if the OS being emul 32 compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
33 uses the 32-bit UID system calls properly ot 33 uses the 32-bit UID system calls properly otherwise.
34 34
35 This affects at least: 35 This affects at least:
36 36
37 - iBCS on Intel 37 - iBCS on Intel
38 38
39 - sparc32 emulation on sparc64 39 - sparc32 emulation on sparc64
40 (need to support whatever new 32-bit 40 (need to support whatever new 32-bit UID system calls are added to
41 sparc32) 41 sparc32)
42 42
43 - Validate that all filesystems behave properl 43 - Validate that all filesystems behave properly.
44 44
45 At present, 32-bit UIDs _should_ work for: 45 At present, 32-bit UIDs _should_ work for:
46 46
47 - ext2 47 - ext2
48 - ufs 48 - ufs
49 - isofs 49 - isofs
50 - nfs 50 - nfs
51 - coda 51 - coda
52 - udf 52 - udf
53 53
54 Ioctl() fixups have been made for: 54 Ioctl() fixups have been made for:
55 55
56 - ncpfs 56 - ncpfs
57 - smbfs 57 - smbfs
58 58
59 Filesystems with simple fixups to prevent 16 59 Filesystems with simple fixups to prevent 16-bit UID wraparound:
60 60
61 - minix 61 - minix
62 - sysv 62 - sysv
63 - qnx4 63 - qnx4
64 64
65 Other filesystems have not been checked yet. 65 Other filesystems have not been checked yet.
66 66
67 - The ncpfs and smpfs filesystems cannot prese 67 - The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in
68 all ioctl()s. Some new ioctl()s have been ad 68 all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
69 more are needed. (as well as new user<->kern 69 more are needed. (as well as new user<->kernel data structures)
70 70
71 - The ELF core dump format only supports 16-bi 71 - The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
72 sh, and sparc32. Fixing this is probably not 72 sh, and sparc32. Fixing this is probably not that important, but would
73 require adding a new ELF section. 73 require adding a new ELF section.
74 74
75 - The ioctl()s used to control the in-kernel N 75 - The ioctl()s used to control the in-kernel NFS server only support
76 16-bit UIDs on arm, i386, m68k, sh, and spar 76 16-bit UIDs on arm, i386, m68k, sh, and sparc32.
77 77
78 - make sure that the UID mapping feature of AX 78 - make sure that the UID mapping feature of AX25 networking works properly
79 (it should be safe because it's always used 79 (it should be safe because it's always used a 32-bit integer to
80 communicate between user and kernel) 80 communicate between user and kernel)
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.