From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 18:55:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647E6106564A for ; Thu, 23 Jul 2009 18:55:35 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6658FC2A for ; Thu, 23 Jul 2009 18:55:35 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 30537 invoked from network); 23 Jul 2009 18:28:53 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Jul 2009 18:28:53 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 9AB1150822; Thu, 23 Jul 2009 14:28:52 -0400 (EDT) To: freebsd-hackers@freebsd.org References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> From: Lowell Gilbert Date: Thu, 23 Jul 2009 14:28:52 -0400 In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> (perryh@pluto.rain.com's message of "Wed\, 22 Jul 2009 22\:00\:58 -0700") Message-ID: <44my6v8d97.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 23 Jul 2009 19:00:49 +0000 Subject: Re: SGID/SUID on scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:55:35 -0000 perryh@pluto.rain.com writes: > DarkSoul wrote: >> Anthony Pankov wrote: >> > SGID/SUID bits don't work with shell scripts, do they? >> >> They don't. >> >> ... if they were applied, the following would occur : >> - execve() syscall reads your script's shebang line, and >> the script interpreter is executed, receiving the specified >> arguments along with the script name. >> - The interpreter then open()s the script file to read it, >> and run the code. >> >> The problem you then are faced with, is that you have a time >> frame defined by the moment between the aforementioned execve() >> and open(), during which it could be possible to unlink/move/ >> whatever the shell script the interpreter is going to open. >> >> You guess where this is going, you have no absolute way of >> guaranteeing you are executing the file you initially planned >> on opening because execution/opening/reading is not, and can't >> be done atomically for shell scripts. > > In principle, it should be possible to fix this exposure by > improving the interface between execve() and the interpreter: > > The execve() syscall already has the script file open to read the > shebang line. Leave it open, and ensure that the interpreter > receives the open descriptor as fd#3 just as 0, 1, and 2 are already > used for stdin, stdout, and stderr. An interpreter supporting this > approach would check whether stdscr (fd#3) is already open, and if > so read from it instead of open()ing the script file. This should > ensure that the script which gets executed is the same inode on > which execve() saw the SGID/SUID bits set, even if the filesystem > has been changed by the time the interpreter has gotten started. > It would be the responsibility of whomever decided to set the > SGID/SUID bits on a particular script to ensure that the interpreter > involved supports the mechanism. > > I vaguely recall having seen a similar (or even identical) approach > suggested some years ago. It may even have been implemented in some > variant of Un*x. That's clever, but how would it work in practice, while common shells and scripting languages may not implement their side of it?