On Fri, Jan 31, 2025 at 09:03:26AM +0000, adithya.balaku...@toshiba-tsip.com wrote: > > > > This temporary file name changes across builds which causes > > reproducibility issues.
All file names in /tmp have to be unpredictable or else this leads to serious security problems. > I am attaching a patch that attempts to fix the issue mentioned here. > The attached patch attempts to solve this with a consistent suffix > appended to the temporary filename. There are at least two problems in this patch. First, what if something has already created a file /tmp/tmpkbd.kbdfile or /tmp/tmpkbd.kbd_linux or /tmp/tmpkbd.setupdir? Setupcon will fail. Anything can make such a file. This can be a previous failed for some reason run of setupcon, an user testing a new version of setupcon, a user who intentionaly does a DOS attack. Second, after you touch the temp file, it is imperative that you test that the touched file is owned by the user executing the script and that it is not a symlink. Otherwise, this can easily lead to the so called symlink attack. These are two problems that I can see. But even if these problems are fixed, I would still feel uneasy about the patch. In the area of security the people never say "the program runs ok in most environments, so it is ok to release it". In the area of security the people don't care whether the program runs ok or not. They care that the program is safe even in the worst possible UNTHINKABLE environment. The bottomline is that using "touch" to create a file in /run (with some appropriate checks) is probably safe. If this fails, you can probably try to create a file in in the home directory of the user running the script (although this would be unmannerly behaviour). However, if you have to create a file in /tmp, then this file has to be created using "mktemp". Anton Zinoviev
