From owner-freebsd-current@FreeBSD.ORG Thu Oct 18 12:32:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9A1516A421 for ; Thu, 18 Oct 2007 12:32:00 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (lindfield.ch [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 96B6D13C448 for ; Thu, 18 Oct 2007 12:32:00 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:59507 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IiUXe-0005op-UL for freebsd-current@freebsd.org; Thu, 18 Oct 2007 12:31:58 +0000 Message-ID: <4717523E.1000403@conducive.net> Date: Thu, 18 Oct 2007 08:31:58 -0400 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <00bd01c810ec$10371230$0c00a8c0@Artem> <8cb6106e0710171143m3dff7546o457192ede76e6598@mail.gmail.com> <012c01c810f3$aafeecf0$0c00a8c0@Artem> <20071017193615.GO9006@server.vk2pj.dyndns.org> <471667DB.1010601@conducive.net> <47170FF1.3050602@moneybookers.com> <471746C7.20306@conducive.net> <47174BE4.6020300@moneybookers.com> In-Reply-To: <47174BE4.6020300@moneybookers.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Broken su in current - trying to fix myself, help needed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 12:32:00 -0000 Stefan Lambrev wrote: > Hi Bill, > > 韓家標 Bill Hacker wrote: >> Stefan Lambrev wrote: >>> Hi, >>> >> *snip* >> >>>> I will not be surprised if it occurs when building as an 'ordinary >>>> user' and does NOT occur when building as root.... >>>> >>>> BNL (BSD's Not Linux).... >>>> >> >>> I see something similar on all ports that have OPTIONS (make config). >>> Here is example (do this as user member of wheel, but not root): >>> >> >> Stop right there. '..NOT root'?? >> >> Why would I DO that? > You can do this by mistake for example. When you have 10 terminals > sometimes you did not pay enough attention are you root or not LOL! trust me to know that one! 50 years since I submitted my first card deck to a mainframe, but I did exactly that - twice, yet - in the last 24 hours.. Including EUID in the 'prompt' just need a hug and kiss, as I use several different shells... > Also you may want only to "read" what is the last configuration of a > port using: make config (not configure!) > and for this you do not have to be root( see permitions of /var/db/ports/) ACK. > Also it's a nice feature in FreeBSD ports, so I really do not know why > not to use it, as it's a feature, but not a bug. > ACK. > Anyway why or why not does not matter. > The only think that matter is that doing this trigger the bug in "su". > Bug that does not exist in 6.2-STABLE or before, and normally bugs are > exploited by users that are not root. > What Artem is seeing is not (yet) a 'bug' in su in my mind. MC is 'in the way' of getting accurate response (smells of the classical DOS 'pause' when in echo-off, and/or at a point in time when stdio is not connected to the VTTY in use). Unless/until mc is ether sorted or taken out of the loop, the result is not conclusive. IOW - I can reproduce the 'fail-to-complete and say so' easily enough in any CLI shell so far mentioned, but I cannot reproduce the 'quietly go away and hide' behaviour in a 'raw' shell. That doesn't mean that su is perfect. But I'd not waste an su coder's time on su so long as there is a lack of transparency / lack of proper error return in mc's script handling. Separate issue. > P.S. /usr/ports/Mk/ look for SU_CMD :) > And? Are you of the opinion that suexec-* et al can over-ride system security when invoked by a non-root EUID caller? I surely hope not... ;-) Bill