On Sun, Mar 19, 2006 at 08:41:14PM +0000, Darren Reed wrote:
> 
> In a discussion about how NetBSD opens and closes nls files way too
> often, it was brought up that there are similar problems with the
> name-number files like /etc/services and /etc/protocols.
> 
> So the problem is, what to do about it?  How can they be made quicker?
> 
> One idea I'd like to discuss is what about using a shared memory map
> that is published by a daemon ?  If the daemon isn't present or the
> map is missing, fall back to the "slow approach."
> 
> The daemon would use kqueue events to know when it should refresh the
> cache as changes to the files are made - this won't work if /etc or the
> mount point the files come from isn't local.
> 
> The file created by the daemon would live in /var/run, perhaps a
> /var/run/nscd.map.
> 
> This file would need to be opened and read only once in the lifetime
> of a program.  The shared memory segment would act as an in-core
> database (maybe 8k-16k) that get*name/get*by* would copy data out
> of before returning it to the caller.  Some use of locking would
> be required to keep people out while it is being updated.
> 
> Unfortunately I can't think of a better name for it than nscd.
> 
> What this solution means in the context of NIS/LDAP serving these
> databases hasn't yet been considered yet.  But in a local files
> approach, I can see the following being cached:
> 
*snip snip*
> /etc/passwd

Just a thought: kill two birds with one stone, let nscd (a privileged
process) write to /etc/passwd, and take the setuid bit off of passwd(1).
When we eliminate setuid programs, we can let even non-superusers
create chroot(2) "jails," valuable protection defective software and
Trojan horses.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933