DragonFly kernel List (threaded) for 2003-12
Re: libcaps thread testing code committed
: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.
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
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).