From owner-freebsd-hackers Mon Mar 27 13:18:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 042BE37BCE8; Mon, 27 Mar 2000 13:18:12 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA55658; Mon, 27 Mar 2000 14:18:09 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA99918; Mon, 27 Mar 2000 14:17:52 -0700 (MST) Message-Id: <200003272117.OAA99918@harmony.village.org> To: David Malone Subject: Re: Linprocfs observation. Cc: hackers@FreeBSD.ORG, des@FreeBSD.ORG, pb@FreeBSD.ORG In-reply-to: Your message of "Mon, 27 Mar 2000 21:01:19 +0100." <200003272101.aa58489@salmon.maths.tcd.ie> References: <200003272101.aa58489@salmon.maths.tcd.ie> Date: Mon, 27 Mar 2000 14:17:52 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200003272101.aa58489@salmon.maths.tcd.ie> David Malone writes: : The "file" file was removed from FreeBSD's /proc code (in 4.0 and : 5.0) because of this, but it is probably important for Linux : emulation so it can't really be removed from the linprocfs code. : I guess this probably warrants at least a note in the man page. File was removed because it was a huge, gaping security hole. It was effectively hard link to the file in question and circumvented some of the usual security protections that the file would otherwise be protected by. : Linux itself is not subject to this problem because it's exe file : is a synthetic symlink pointing to the executable, not something : which returns the executables actual vnode. And that's why it is still in the tree. A symbolic link doesn't have the security issues that the hard link has. : Also, on Linux the : symlink is only readable by the process' owner. This suggests the : following possible work around: : 1) Add a directory /linproc/pid/private which is only : executable and readable by the process' owner. : 2) Make the "exe" file in /linproc/pid/ a symlink to : "./private/exe", which is the file which gives : you the executables real vnode. : I think this will give the same behavior as the Linux procfs, and : expose less suid stuff. It would be necessary to do something very : like this if we ever have to implement /linproc/pid/fd/xx. Why bother? No body should be using file/exe at all. It is a useless misfeature. What actually uses it? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message