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: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Mon, 8 Dec 2003 20:03:17 +0100

On Mon, Dec 08, 2003 at 10:21:33AM -0800, Matthew Dillon wrote:
>     I'm going to take a short break and finish up the IPC code.  I've been
>     pondering the new IPC API over the weekend (the one that I proposed
>     earlier and mocked up in libcaps) and it still looks good.  With 
>     direct kernel support we will be able to move things like 
>     getpwuid() and so forth into IPC services leaving only emergency
>     flat-file support in libc for when IPC is not running (during boot and
>     during shutdown), and also to allow sysop access when it breaks.

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

> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>
> 



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