On Fri, May 24, 2024 at 08:58:55AM -0700, Aleksa Sarai wrote: > > Though, regardless of the attack you are worried about, I guess we are > in agreement that a unique mount id from name_to_handle_at() would be a > good idea if we are planning for userspace to use file handles for > everything. I somewhat disagree - the information needed to validate and restrict the scope of the filehandle needs to be encoded into the filehandle itself. Otherwise we've done nothing to reduce the potential abuse scope of the filehandle object itself, nor prevented users from generating their own filehandles to objects they don't have direct access to that are still accessible on the given "mount id" that are outside their direct path based permission scope. IOWs, the filehandle must encode the restrictions on it's use internally so that random untrusted third parties cannot use it outside the context in which is was intended for... Whether that internal encoding is a mount ID, and mount namespace identifier or something else completely different is just a detail. I suspect that the creation of a restricted filehandle should be done by a simple API flag (e.g. AT_FH_RESTRICTED), and the kernel decides entirely what goes into the filehandle to restrict it to the context that the file handle has been created within. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
