Exactly. The relatively smooth upgrading of software on Unix-like systems is because you can unlink the old file and create a new file with the same name. The old one will continue to exist, with its old data, as long as a process has it open. If you try to fix the suid binary problem by forcibly removing a file, or overwriting its contents, then you risk breaking running code. (Since writing bytes to a file is not atomic, you could theoretically introduce new security holes by overwriting the contents of a suid binary. What if someone runs it halfway through the update, when it contains a mixture of old and new code?) One answer would be to move the suid flag out of the inode and put it in the directory entry. Then you could make as many links to a file as you wanted, but you wouldn't be able to get the suid magic (unless, of course, you have permission to set the suid bit anyway). But given the conservatism of Unix-like systems and the large amount of filesystem code that would have to change, I can't see this happening soon.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds