From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:01:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B11416A41F for ; Wed, 31 Aug 2005 19:01:01 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0819E43D49 for ; Wed, 31 Aug 2005 19:01:00 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 766AFA2FD3; Wed, 31 Aug 2005 21:00:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 63DA52287D; Wed, 31 Aug 2005 21:00:59 +0200 (CEST) Date: Wed, 31 Aug 2005 21:00:59 +0200 From: Jilles Tjoelker To: Michael Bushkov Message-ID: <20050831190059.GA23652@stack.nl> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830172127.E5409@stinger.cc.rsu.ru> X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Dan Nelson Subject: Re: [PATCH] caching daemon release and nsswitch patches 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: Wed, 31 Aug 2005 19:01:01 -0000 [cc list stripped] On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: > We can't ensure that, I guess. In the upcoming version (before the 1st of > September), the cache would be per-user. This would solve all the security > problems. In a little while, I'll implement the ability for cached to act > as nscd. So you'll be able to choose the behaviour. What about setuid/setgid programs then? setuid root programs can use root's cache, perhaps a similar thing could be done for other setuid programs, but what about setgid? perhaps don't cache at all for set*id programs (issetugid(2))? -- Jilles Tjoelker