| |||||||||||||
|
| |||||||||||||
Standards, the kernel, and PostfixStandards, the kernel, and PostfixPosted Aug 21, 2008 14:44 UTC (Thu) by rwmj (guest, #5474)In reply to: Standards, the kernel, and Postfix by epa Parent article: Standards, the kernel, and Postfix
No, package managers should just remove the setuid bit before unlinking the file. This doesn't affect running programs. It does affect someone who starts to run the program at the moment that the suid bit is removed, but this is already a problem during package upgrades (the file is temporarily removed, so attempts to run it can fail briefly). It's actually possible that package managers do this correctly already, since this problem is very old and well-known. Rich.
(Log in to post comments)
Standards, the kernel, and Postfix Posted Aug 21, 2008 18:48 UTC (Thu) by vmole (guest, #111) [Link] No, package managers should put the file in the proper directory with a unique name (e.g. foo.package_new) with proper permissions and ownership, and then rename(2) the proper name to the unique name. This way there's never a time when '/bin/foo' is anything but the proper old entry or the proper new entry, since rename(2) is atomic. Exisiting users of the file won't see the change - they've got an open descriptor to the old file, which remains on disk until the last open descriptor is closed.
How to replace an executable... Posted Aug 22, 2008 6:08 UTC (Fri) by faramir (subscriber, #2327) [Link] There seem to be three issues: 1. Atomic replacement of an executable (by name) 2. Removing permissions from potentially hard linked old copies (by inode) 3. Reporting possible nefarious activities by hard linkers. I think this sequence deals with them all: 1. Hard link canonical name of old executable to first temporary name. 2. Create new executable with second temporary name and appropriate privs. 3. rename() second temporary name to canonical name (this is atomic). 4. Chown/chmod first temporary name to remove any special privileges, execute bits, etc. 5. stat() first temporary name and report if there is more then one link (Should be just one from first temporary name at this point). 6. Unlink first temporary name. At the end of the sequence, you will have atomically replaced the executable, removed any special privileges from any links people may have hidden away, and reported (to the extent possible without a full search of the filesystem) that somebody has been linking to executables. Of course, the sendmail example is a bad one as typically there is more then one valid link. 'sendmail' and 'newaliases were traditionally the same program. I know of no way to atomically make a bunch of links to one program so the best I can think of would be to make a bunch of temporary names for the new execuable and then rename() them all into place sequentially in steps 2 and 3. Steps 4-6 could remain the same and would still be able to accurately report improper links while at the same time making them useless.
|
|
||||||||||||