DragonFly BSD
DragonFly kernel List (threaded) for 2006-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: More on system lookup daemon


From: Gary Thorpe <gathorpe79@xxxxxxxxx>
Date: Mon, 06 Feb 2006 13:49:56 -0500

I think a group at a university did some work on an authentication daemon as an alternative to dynamic binding (as used in PAM, NSS), but I cannot recall details. Searching the freebsd-current and freebsd-hackers mailing list archives should provide some information on this.

Eli Green wrote:
Well, I've finally managed to book enough time on my own computer (lousy
roommates...) to start experimenting with caps and I've been mulling
over the design of the NSS type daemon.

NSS (at least on Linux, where it is as well documented as any other part
of Linux), it seems that they just dynamically load function pointers
based on the C library function you want to call. For example, the
compat module would be a shared library with _compat_getpwent symbols,
or something like that.

That's fine for something that gets dynamically loaded into your own
process space and you get the joy of using all the globals you want, but
doesn't really work in the case we're looking at.

So right now I'm imagining a forward-only cursor system. The only entry
points into a module would be:

    typedef struct query_op {
        char *field;
        char *value;
    } query_op_t;

    typedef struct query {
        char *db;
        struct query_op *ops;
    } query_t


cursor_t cursor_init(query_t *query) { }

    void *
    cursor_next(cursor_t cursor)
    {
    }

    void
    cursor_destroy(cursor_t cursor)
    {
    }

query is meant to be encodable by CAPS IPC, naturally. getpwuid, for
example, would simply provide a query struct looking something like
{"passwd", {"uid", "5"}} to cursor_init and call cursor_next once.

While this makes it very easy to implement modules (it should be
possible to write an NSS compatibility module and it would be very easy
to write SQL or LDAP modules), is it worth having such a generic
interface when cursor_next is going to be returning database-specific
pointers anyway?

(Or is it? Could it just return key-value pairs, and based on the
database requested, the daemon itself could then pack them into structs
before sending them back to the client?)

Please let me know in the harshest language available if I'm being an
idiot here.

(Oh, I assumed cursor_t would be something small, a 32 or 64 bit int, to
be used by the module as it sees fit).





[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]