Can we record comm in fdtable at open()?

Posted Dec 15, 2024 7:35 UTC (Sun) by consend (guest, #132320)
Parent article: The kernel's command-line commotion

I understand that the only accurate information fexecve() can use is the file descriptor (fd). So how about selectively storing comm in the fdtable during open? This would allow fexecve() to read it. However, this might bring some issues, such as increasing the burden of open(), requiring more memory, etc., or there might be some obvious problems that I haven't thought of?

Can we record comm in fdtable at open()?

Posted Dec 15, 2024 16:48 UTC (Sun) by viro (subscriber, #7872) [Link] (1 responses)

First of all, fdtable is obviously wrong place for anything of that sort - you'd have to copy that on dup(), fork(), etc.; if anything, it's a property of open file, not of a descriptor. Putting the last component of pathname that had been used to open a file into resulting struct file... Theoretically doable, but that would cost quite a bit, with no clear benefit - you'd have to do that to all files, just for the sake of vanishingly small subset that would be involved in fexecve(), and usefulness of fexecve() itself is not obvious.

Can we record comm in fdtable at open()?

Posted Dec 18, 2024 12:22 UTC (Wed) by consend (guest, #132320) [Link]

Thank you for your reply! I realized that putting it in the fdtable was indeed a wrong idea. Intuitively, the same file instance should share the same name, and placing it in the fdtable is semantically unclear and violates the lightweight design of descriptors. Just like you said, it's a property of open file, not of a descriptor. Additionally, you mentioned saving filenames for all files. I have simply thought about adding a flag to control whether to save through the open function, but indeed, adding a flag for an extremely small number of special cases may not be a good choice.