Mauro Carvalho Chehab | e45b082 | 2017-05-14 13:51:39 -0300 | [diff] [blame] | 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 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 36 | |
Mauro Carvalho Chehab | e45b082 | 2017-05-14 13:51:39 -0300 | [diff] [blame] | 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) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 42 | |
| 43 | - Validate that all filesystems behave properly. |
| 44 | |
| 45 | At present, 32-bit UIDs _should_ work for: |
Mauro Carvalho Chehab | e45b082 | 2017-05-14 13:51:39 -0300 | [diff] [blame] | 46 | |
| 47 | - ext2 |
| 48 | - ufs |
| 49 | - isofs |
| 50 | - nfs |
| 51 | - coda |
| 52 | - udf |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 53 | |
| 54 | Ioctl() fixups have been made for: |
Mauro Carvalho Chehab | e45b082 | 2017-05-14 13:51:39 -0300 | [diff] [blame] | 55 | |
| 56 | - ncpfs |
| 57 | - smbfs |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 58 | |
| 59 | Filesystems with simple fixups to prevent 16-bit UID wraparound: |
Mauro Carvalho Chehab | e45b082 | 2017-05-14 13:51:39 -0300 | [diff] [blame] | 60 | |
| 61 | - minix |
| 62 | - sysv |
| 63 | - qnx4 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 64 | |
| 65 | Other filesystems have not been checked yet. |
| 66 | |
Matt LaPlante | 84eb8d0 | 2006-10-03 22:53:09 +0200 | [diff] [blame] | 67 | - The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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) |