Date: Mon, 14 Apr 2003 08:05:43 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: "Michael A. Bushkov" <bushman@rsu.ru> Cc: and@rsu.ru Subject: Re: nsswitch implementation Message-ID: <20030414130543.GA55015@madman.celabo.org> In-Reply-To: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru> References: <30983F67-6E77-11D7-BB0D-000393BC13C6@rsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 14, 2003 at 04:47:02PM +0400, Michael A. Bushkov wrote: > Greetings! > > We are currently working on alternate nsswitch implementation for > FreeBSD. We want to make this implementation more flexible and powerful > than the current one. :-) You will see a new nsswitch committed by me to FreeBSD-CURRENT within the next two weeks. > Our idea is to make 3-level structure of nsswitch: > > 1) libc functions talking to the level2 daemon > > 2) Special daemon (nssd) accepting queries from > libc, passing them to level3 (modules) and sending answers > back to libc > > 3) DSO modules, containing functions doing real work > to obtain requested information from any source or > database (for example nss_files.so, nss_dns.so and so on) This structure is overkill, IMHO. Such a structure requires that all nsswitch consumers in libc marshall arguments. Also, some NSS modules already have their own daemon, e.g. winbind. That is the direction that is likely to continue, as it fits the model already established by Solaris, Linux, and IRS. > The daemon (level 2) should be able do dynamically open modules - we > can't call dlopen() directly from libc. Sure we can. You just can't if you are a statically-linked executable. [The implementation that will be committed shortly allows for building an NSS module with world so that statically-linked binaries are also supported.] > At the moment we have a working alpha-version of daemon, nss_files > module and some rewritten libc functions. And there is one problem: > behaviour of modules should be different for regular users and for > root. Currently (in libc) this is done with the help of > geteuid(). This is not applicable for modules since their function > are called by the daemon but not the originating process itself. > > We see two implementable solutions: > > 1. Run 2 daemons to separate root and non-root queries. > > 2. Pass uid information to the module functions and let them use it > instead of > geteuid() 3. Use a UNIX domain socket to talk to the daemon and utilize credential passing (SCM_CREDS). See the RPC libraries for an example. > And another 'theoretical' solution: to intersept geteuid() calls from > modules. > > We defenitely need some suggesions and discussion. Any help will be > greatly > appreciated. > > Pleas keep CC lines in replies since we're not on the list. I'm futzing with resolver stuff (scared to break it :-). I think I'll try to quickly bring in the new nsdispatch core and the getpw*, getgr* routines for now so that others can see what is going on. Cheers, -- Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030414130543.GA55015>