[ On Wednesday, January 24, 2001 at 18:39:24 (+0900), Noriyuki Soda wrote: ]
> Subject: Re: bin/12017: how to enable multibyte locale (and problem around it)
>
> If the issetugid(2) is true, the library only load the module
> from trusted directory, as you see.

That's not good enough.  No code must ever be loadable into a process
started from a static binary.  That's what the word "static" means!  ;-)

I still agree that processes that are authorised to load new code should
be permitted to do so regardless of whether their main load image was
linked against any shared library or not.  I just want a simple compile
or link time "switch" that will allow me to generate binaries that will
be guaranteed never to try loading more code on their own.  If I can get
the best internationalisation support available at link time in those
static binaries too then that's all the better.

The cost of intarnationalising binaries is definitely going to be size
and perhaps even performance.   For those of us who have already
preculded the use of dynamic loading to share code then that size
increase is definitely going to be bigger.  I understand this and I
certainly accept these costs as necessary.

Furthermore in any "open system" I don't find any need ever to use
dynamic loading of shared libraries as a mechanism for extensibility (or
even just bug fixes, for that matter).  This doesn't even have to
violate NetBSD's goal of providing a platform that doesn't further
restrict a third-party developer since that developer has many options
available to them which do not require that they also make their source
code available (and indeed one of those options is that the vendor is
free to make run-time dynamic loading available in *their* libc!).

I challenge anyone who thinks otherwise to ask any number of third party
developers (I'm one of them! :-) just how often they would consider
shipping new dynamically loadable code to their customers, especially
just for the purpose of extending some of the i18n APIs in order to
provide support for a new locale.  My answer of course is "Never!" (and
I don't just mean on ultra-secure boxes, but even on ordinary production
servers in a non-public environment).  If one of my customers suddenly
needs a getdate() routine that supports some new locale then [or any
other i18n API which would need re-coding to do the job], then I'll
provide them with either complete new binaries as necessary, or even
provide a complete new system release that can be easily used to upgrade
a production server.  Furthermore my customers know that they can
independently obtain all of the source code and re-build their own
systems.  Providing new i18n support for new locales does not really
require dynamic binary extensibility in any open source environment.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>