nsswitch implementation

Danny Braniss danny at cs.huji.ac.il
Mon Apr 14 06:13:55 PDT 2003


Greetings 2u2!
	I won't go into the merrits of a new/er implementation, but
i keep wondering the merrits of a different access for root/non-root.
AFAIK, the only problematic issue is with the hashed-password visibility, and
if that is so, then a much simpler solution should be available.

danny

> 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.
> 
> 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)
> 
> The daemon (level 2) should be able do dynamically open modules - we
> can't call dlopen() directly from libc.
> 
> 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()
> 
> 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.
> 
> Michael A. Bushkov
> Computer Center of Rostov State University
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 




More information about the freebsd-hackers mailing list