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