On Fri, Oct 11, 2024 at 11:27:45PM +0900, Tetsuo Handa wrote: > On 2024/10/11 20:04, Mickaël Salaün wrote: > > On Fri, Oct 11, 2024 at 07:12:17PM +0900, Tetsuo Handa wrote: > >> On 2024/10/11 0:26, Mickaël Salaün wrote: > >>> When a filesystem manages its own inode numbers, like NFS's fileid shown > >>> to user space with getattr(), other part of the kernel may still expose > >>> the private inode->ino through kernel logs and audit. > >> > >> I can't catch what you are trying to do. What is wrong with that? > > > > My understanding is that tomoyo_get_attributes() is used to log or > > expose access requests to user space, including inode numbers. Is that > > correct? If yes, then the inode numbers might not reflect what user > > space sees with stat(2). > > Several questions because I've never seen inode number beyond UINT_MAX... > > Since "struct inode"->i_ino is "unsigned long" (which is 32bits on 32-bit > architectures), despite stat(2) is ready to receive inode number as 64bits, > filesystems (except NFS) did not use inode numbers beyond UINT_MAX until now > so that fs/stat.c will not hit -EOVERFLOW condition, and that resulted in > misuse of %lu for e.g. audit logs? Yes, I think other filesystems (e.g. tmpfs) only enable 64-bit inodes on 64-bit architectures. > > But NFS was already using inode numbers beyond UINT_MAX, and e.g. audit logs > had been recording incorrect values when NFS is used? Correct, all the logs with NFS inodes are wrong. > > Or, some filesystems are already using inode numbers beyond UINT_MAX but the > capacity limitation on 32-bit architectures practically prevented users from > creating/mounting filesystems with so many inodes enough to require inode > numbers going beyond UINT_MAX? I think so but I didn't take a look at all other filesystems. > > > > You are trying to fix out-of-sync between stat(2) and e.g. audit logs > rather than introducing new feature, aren't you? Yes > > Then, what you are trying to do is OK, but TOMOYO side needs more changes. > Since TOMOYO is currently handling any numeric values (e.g. uid, gid, device > major/minor number, inode number, ioctl's cmd number) as "unsigned long", > most of "unsigned long" usage in TOMOYO needs to be updated to use "u64" > because you are about to change inode number values to always-64bits. > OK, could you please send a full patch in reply to this email? I'll include it in the next patch series.
