From owner-freebsd-security@FreeBSD.ORG Mon May 21 01:43:31 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7F3616A468 for ; Mon, 21 May 2007 01:43:31 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF0613C48C for ; Mon, 21 May 2007 01:43:31 +0000 (UTC) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from kulesh.obluda.cz (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id l4L1hNmL053792 for ; Mon, 21 May 2007 03:43:29 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4650F93A.3080603@obluda.cz> Date: Mon, 21 May 2007 03:43:22 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070327 SeaMonkey/1.1.1 MIME-Version: 1.0 CC: freebsd security References: <20070519130533.722e8b57@vixen42> <86bqgfh4w0.fsf@dwp.des.no> <20070520120142.39e86eae@vixen42> <86tzu7ifp2.fsf@dwp.des.no> <20070520132410.58989605@vixen42> <4650939B.6020004@obluda.cz> <20070520200310.4a79954e@vixen42> In-Reply-To: <20070520200310.4a79954e@vixen42> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PAM exec patch to allow PAM_AUTHTOK to be exported. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2007 01:43:31 -0000 Zane C.B. napsal/wrote, On 05/21/07 02:03: >> 3. want's to be PAM aware, but it's programmer is too lazy to write >> it the clean way (as regular pam module) - we need the patch >> >> The patch shall be rejected because the only purpose of it >> is to support lazy programmers creating hacks instead of solutions. > > Actually it does not support lazy programming, but makes life of a > makes life of a administrator easier. The contrib/smbfs/mount_smbfs/mount_smbfs.c is very short and simple. Writing PAM module with same functionality require almost the same amount of time as patching it. In advance, you need catch not only pam_sm_session_open but pam_sm_session_close (i assume you plan to umount resource also). Unfortunately (unless I miss something) pam_exec has no way to pass about 'direction' to called program. You can't use simple heuristic "when not mounted mount it and vice versa" also because the same user can have more than one simultaneous active session. The logic you need to implement seems to require much more coding than simple patch on either pam_exec nor mount_smbfs ... pam_exec in chain more hurts than helps. IMHO, of course. But further discussion about it seems not to be security related, so we should not continue here. Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz