>>Perhaps the Sun kernel developers aren't aware that it's bad to allow >>tracing after a program changes uid, but obviously they are aware that >>it's bad to allow tracing of an unreadable program. In fact, the /proc >>documentation identifies this as a security measure. Just to complete the information of the state of Solaris 2.x and core dumps. >This has long been fixed in Solaris. (I think it was fixed before >2.6 was released; there's a patch for Solaris 2.5.1 also) The relevant bug is: 4042883 Patch for 2.5.1 is the kernel update (103640) at rev 13 or higher. It is integrated into 2.6, without patches. >Since the patch, programs that are set-uid, call set*uid or set*gid cannot >be traced and cannot dump core. (Which upset yet another batch of >customers so there's an option in Solaris 7 to make set-uid programs >dump core if the kernel is so configured) No core dump can be created ... 1. If the resource limit RLIMIT_CORE has been set to 0 for the process. Refer to setrlimit(2) and ulimit(1) for more on this. 2. If the file "core" exists in the current directory and is not a regular file (i.e. is a symlink, block or character special-file, etc) 3. If the current directory is part of a filesystem which is mounted read-only 4. If the file "core" exists in the current directory and is not writeable to the user-id associated with the process trying to dump core. 5. In Solaris 7, if the kernel cannot open the file "core" in the current directory O_EXCL, which might happen if another process is trying to dump core there at the same time. 6. If the process is setuid or setgid or has changed its uid or gid (by virtue of being root and executing any of the set*id(2) system calls). As Casper pointed out this upset some people so, In Solaris 7 these processes can be granted permission to dump core (at the risk of compromising secure data) by setting allow_setid_core to 1 in /etc/system, note that this is system wide so all set*id() programs will now be able to dump core, there is no facility to specify which programs. -- Darren J Moffat
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:53 PDT