On Fri, Jan 16, 2009 at 01:45:44PM -0700, Michael Loftis wrote: || --On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich || <johannes@physik.blm.tu-muenchen.de> wrote: || > IIRC, a hard link is the same file called two different names. If || > dpkg/apt change the file in one location (security update), the other || > one will be changed as well [1]... Hm! If it's not already that way, it might be a nice idea for a package manager to reset setuid bits before removing a setuid executable. || That only holds true of edit-in-place. Something that most packaging || systems do not do, the reason being is that with the way modern || systems/kernels execute code, this would modify running code (They || generally mmap the code, readonly, into the processes address space). I expect the mmapped executable to be private and copy on write, so you can write all you want but you can't modify the map that's already in use by the process. You'll only manage breaking the sharing. I know you can delete the mmapped file. || FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use || error. However, you can't create a hard link on a file you don't own, you || can't do it across drives, and I don't think your hardlinked copy retains || SUID bits....The last bit I could be wrong though. Yes, you're wrong there. Permissions are attached to the inode, not the directory entry. (That would be something, hard link someone else's files, change the permissions and hack it...) || > You'd have to *copy* the hard linked file, but that would still not || > allow you to copy it back later or to retain it's suid properties. Your copy will be yours. If you decide to set the suid bit on your copy, it would be setuid to *you* instead of to the other guy. Ciao. Vincent. -- Vincent Zweije <zweije@xs4all.nl> | "If you're flamed in a group you <http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?" [Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.
Attachment:
signature.asc
Description: Digital signature