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