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

Re: libcaps thread testing code committed


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 9 Dec 2003 10:32:16 -0800 (PST)

:After a bit more thinking about NSS and IPC, do we even need that?
:I mean for mounting the critical filesystems it is not needed. If we
:have a complex backend like LDAP which needs network access, having
:a stackable facility in the NS server is enough or alternativly start
:a bootstrap version and later update to the "full" NS configuration.
:That way libc only needs very basic fall-back functions generating
:e.g. some kind of template entry with sprintf(pw_name,"%d",uid) for
:getpwuid and the like. The sysop hopefully knows the uid of root if
:he spots it with ps ;) Authentication in such a situation is somewhat
:different, since login or its backend can get the necessary fall back
:support directly, they need to anyway since providing pw_password
:via NSS is not really useful, is it? The situation is similiar to
:a hosed up /etc, once you got a shell you do not need the uid/gid lookup.
:
:> 
:>     A bunch of things are coming together all at once, it's kind hard to
:>     pick and choose what piece of pounce on next!
:
:It is definitly an interesting month.
:
:Joerg

    I think we we need some sort of dirt-simple flatfile access built into
    libc.  There are a number of situations in early boot as well as when you
    drop into single-user and/or when you are rebooting that we want to
    retain basic root functionality for.

    It definitely does not need to implement all the bells and whistles, just
    enough that a sysop can still do work as root.  So, e.g. hard-wiring
    /etc/group lookups would work but we'd probably still want to parse 
    /etc/master.passwd.

    One interesting fallout of using the IPC mechanism is that we no longer
    have to DBM system files.  The IPC server's flat file support can load
    the flat file once and hash it in memory, and then simply check to see
    if it has been modified.  If kqueue() does not already have the ability
    to detect file modifications we can add that feature (I seem to recall
    that kqueue does have the ability, or is very close to having the ability).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



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