From owner-freebsd-arch@FreeBSD.ORG Fri Mar 5 13:28:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD42B16A4CE; Fri, 5 Mar 2004 13:28:35 -0800 (PST) Received: from smtp.aaanet.ru (smtp.aaanet.ru [80.80.111.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE1B743D39; Fri, 5 Mar 2004 13:28:34 -0800 (PST) (envelope-from bushman@rsu.ru) Received: from [80.80.101.35] (helo=localhost.localdomain) by smtp.aaanet.ru with esmtp (Exim 4.30; FreeBSD) id 1AzMxl-0003cM-JT; Sat, 06 Mar 2004 00:34:50 +0300 To: Gordon Tetlow From: Michael Bushkov Organization: Rostov State University Content-Type: text/plain; format=flowed; charset=windows-1251 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sat, 06 Mar 2004 00:27:58 +0300 Message-ID: User-Agent: Opera7.23/FreeBSD M2 build 518 cc: and@rsu.ru cc: Jordan K Hubbard cc: arch@freebsd.org cc: hackers@freebsd.org cc: os@rsu.ru cc: bork@rsu.ru Subject: Re: IPC nsswitch implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2004 21:28:35 -0000 I understand this. There are some problems in making current nss-modules compatible with our implementation. The main problem is process euid. When you're using current nss-modules they work as part of your program - and geteuid functions work correctly. But when lookupd is used, euid of the process is lookupds' euid. And that's a problem. There are two possible solutions, i think: 1) We can run 2 daemons. One with root euid. And one with "simple user" euid. Client side will choose one or another to connect. But this way is rather expensive. 2) We can try to change geteuid function in modules for our function, which will return thread-specific value, which would be set by daemon. The minus is that we, however, will need to recompile nss-modules. And another thing. When we use lookupd daemon we can optimize it work much. For example, modules can use persistent-connections. It can be very useful. But, returning to your question :) It is possible, i think. There are some disadvantages, but it's possible. Of course, using modules, developed for lookupd would be better, but as "compatibility" decision we can try to implement usage of current nss-modules. Michael Bushkov, Software Engineer, Rostov State University On Fri, 5 Mar 2004, Gordon Tetlow wrote: > On Fri, Mar 05, 2004 at 10:41:33PM +0300, Michael Bushkov wrote: > > > > Our implementation of lookupd is a demonstration > > of the approach for the FreeBSD-specific IPC implementation > > of nsswitch. Its architecture is > > flexible enough to implement all the features you have mentioned. > > The version that we have sent isn't a finished project. It's in the > > development stage and caching is currently our main task. We hope to > make > > caching in the nearest future. > > We'll try to release stable and quite full version (i mean caching, > LDAP > > module and so on) as soon as we can. > > > > Our questions are: > > 1) What do you think about our whole approach to the IPC implementation > > development? > > 2) Is there an opportunity to use our implementation of lookupd in the > > FreeBSD project? > > The thing that I'm most interested in is getting support for the existing > NSS modules out there (nss_ldap being my personal interest). Is there a > way with the IPC based model to make the existing in-process modules > (I'm thinking nss_winbind and nss_ldap) work with the IPC daemon? If not, > I doubt you'll get a whole lot of support for the IPC model because it > will cause us to incur a maintence cost to make these other very useful > modules work.