From owner-freebsd-questions@FreeBSD.ORG Wed Jan 14 13:33:50 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC27716A4CE for ; Wed, 14 Jan 2004 13:33:50 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D0143D58 for ; Wed, 14 Jan 2004 13:33:49 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i0ELYG24002044 for ; Wed, 14 Jan 2004 13:34:16 -0800 (PST) Received: from [10.1.1.193] (nfw2.codefab.com [66.234.138.66]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i0ELXmU1010288 for ; Wed, 14 Jan 2004 13:33:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <444quzs2uj.fsf@be-well.ilk.org> References: <000d01c3d980$5521b6e0$5858269e@JANELLE> <0D7DAA44-4615-11D8-AA98-003065ABFD92@mac.com> <444quzs2uj.fsf@be-well.ilk.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56C71CB2-46D9-11D8-AA98-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org From: Charles Swiger Date: Wed, 14 Jan 2004 16:33:48 -0500 X-Mailer: Apple Mail (2.609) Subject: Re: binary execute restrictions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:33:51 -0000 On Jan 13, 2004, at 9:04 PM, Lowell Gilbert wrote: > I suspect that a restricted shell isn't going to be appropriate in > this case. Restricted shells are useful for avoiding shooting > yourself in the foot, but they're really not intended to be secure. You're probably right that my suggestion is only a partial solution, but using a restricted shell and chroot()ing these users to a home directory that isn't owned/writable by that UID should come pretty close to solving the Original Poster's problem. It might also be the case that the OP might be better off not generating "normal user accounts", but using application-specific user databases (such as found in software like Cyrus) to give controlled access to a particular service. -- -Chuck