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? But NFS was already using inode numbers beyond UINT_MAX, and e.g. audit logs had been recording incorrect values when NFS is used? 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? You are trying to fix out-of-sync between stat(2) and e.g. audit logs rather than introducing new feature, aren't you? 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.
