I thought the enclosed conversation would be of interest. prior to contacting solar designer i did look at the fileutils (4.1) info for cp and was unable to find the information he mentions. most users might not pick up on this subtlety and the results could be disastrous. fractoid
On Sat, Jul 07, 2001 at 07:08:38PM -0400, [EMAIL PROTECTED] wrote: Hi, > i'd like to ask your opinion. let's say i have a file (bin) which is suid a > non privileged user, which i copy to another file while i'm root. > The new file is now SUID *ROOT*. a reputable linux kernel developer informs > me that this is expected behavior for root, and i find this incredibly > dangerous, and unexpected. (This has nothing to do with the kernel, it's a property of cp.) > Is this something that should be prevented in secure systems? Yes, I think so. This is really the expected behavior if you read the texinfo documentation for GNU fileutils, but I agree that most people wouldn't expect cp to leave the SUID and SGID bits when cp isn't told to also preserve the file's ownership. `-p' `--preserve' Preserve the original files' owner, group, permissions, and timestamps. In the absence of this option, each destination file is created with the permissions of the corresponding source file, minus the bits set in the umask. *Note File permissions::. I think that cp without -p (and -a) should also not copy the three bits not controllable with umask. Feel free to forward this to <[EMAIL PROTECTED]> and please CC me if you do so. -- /sd
