lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <YthCucuMk/SAL0qN@mit.edu> Date: Wed, 20 Jul 2022 14:00:25 -0400 From: "Theodore Ts'o" <tytso@....edu> To: Matthew Wilcox <willy@...radead.org> Cc: "Darrick J. Wong" <djwong@...nel.org>, Jeremy Bongio <bongiojp@...il.com>, linux-ext4@...r.kernel.org, linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [PATCH v4] Add ioctls to get/set the ext4 superblock uuid. On Wed, Jul 20, 2022 at 03:11:21PM +0100, Matthew Wilcox wrote: > Uhhh. So what are the semantics of len? That is, on SET, what does > a filesystem do if userspace says "Here's 8 bytes" but the filesystem > usually uses 16 bytes? What does the same filesystem do if userspace > offers it 32 bytes? If the answer is "returns -EINVAL", how does > userspace discover what size of volume ID is acceptable to a particular > filesystem? > > And then, on GET, does 'len' just mean "here's the length of the buffer, > put however much will fit into it"? Should filesystems update it to > inform userspace how much was transferred? What I'd suggest is that for GET, the length field when called should be the length of the buffer, and if the length is too small, we should return some error --- probably EINVAL or ENOSPC. If the buffer size length is larger than what is needed, having the file system update it with the size of the UUID that was returned. And this would be how the userspace can discover size of the UUID. In practice, though, the human user is going to be suppliyng the UUID, which means the *human* is going to have to understand that "oh, this is a VFAT file system, so I need to give 32-bit UUID formatted as DEAD-BEAF" or "oh, this is a ntfs file system, so I need to enter into the command line a UUID formatted as the text string A24E62F14E62BDA3". (The user might also end up having to ntfs or vfat specific uuid changing tool; that's unclear at this point.) As far as Jeremy's patch is concerned, I don't think we need to change anything forthe SET ioctl, but for the GET util, it would be better in the extremely unlikely case where the user pass in a length larger than 16 bytes (say, 32), that we return the 16 byte UUID, and update the length field to be 16 bytes. I don't think it's strictly necessary, since in practice there is no reason why a file system's volume identifier would ever be larger than 16 bytes --- the chances that we might need an extra 240 bytes to specify a multiverse identifier seems.... unlikely. :-) - Ted
Powered by blists - more mailing lists