diff options
Diffstat (limited to 'Documentation/admin-guide/highuid.rst')
-rw-r--r-- | Documentation/admin-guide/highuid.rst | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/Documentation/admin-guide/highuid.rst b/Documentation/admin-guide/highuid.rst new file mode 100644 index 000000000000..6ee70465c0ea --- /dev/null +++ b/Documentation/admin-guide/highuid.rst | |||
@@ -0,0 +1,80 @@ | |||
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 | ||
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: | ||
36 | |||
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) | ||
42 | |||
43 | - Validate that all filesystems behave properly. | ||
44 | |||
45 | At present, 32-bit UIDs _should_ work for: | ||
46 | |||
47 | - ext2 | ||
48 | - ufs | ||
49 | - isofs | ||
50 | - nfs | ||
51 | - coda | ||
52 | - udf | ||
53 | |||
54 | Ioctl() fixups have been made for: | ||
55 | |||
56 | - ncpfs | ||
57 | - smbfs | ||
58 | |||
59 | Filesystems with simple fixups to prevent 16-bit UID wraparound: | ||
60 | |||
61 | - minix | ||
62 | - sysv | ||
63 | - qnx4 | ||
64 | |||
65 | Other filesystems have not been checked yet. | ||
66 | |||
67 | - The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in | ||
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) | ||