Subject: Re: Making file-based getXent quicker
To: None <tech-userlevel@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-userlevel
Date: 03/20/2006 00:59:07
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