From: Noriyuki Soda <soda@sra.co.jp>
Subject: locale library (was Re: Back in June...)
Date: Sat, 8 Jan 2000 02:27:38 +0900 (JST)
Message-ID: <200001071727.CAA05025@srapc342.sra.co.jp>

> There are numbers of problems to integrate this to NetBSD, though.
> For example,
> 	- NetBSD has a problem to call dlopen()/dlsym()/... from
> 	  functions in libc. (FreeBSD doesn't have this particular
> 	  problem)

Currently, this runelocale (XPG4DL) library has the peculiar functions
named ___locale_dl* instead of native dl* functions on the NetBSD/ELF
platform.  The background of this problem:

  - GNU ld does not embed all unreferenced global symbols into
    .dynsym section of executable in default of -export-dynamic option.
    -export-dynamic option is usually unused.
  - The body of dl* functions are defined in the startup code (crt0.c)
    on the current NetBSD.
  - So far, there is no reference to dl* functions from inside of libc.

Thus, if new function using dl* functions is added into libc,
ld.so cannot resolve such functions for the old binaries which is linked
with old libc.
I think that dl* functions should be defined in libc instead of crt0.c.


> 	- Native issetugid(2) system call is really needed, otherwise
> 	  very serious security flaw will appear. Since this library
> 	  loads user configurable shared object, this user
> 	  configuration feature should be avoided on setuid/setgid
> 	  executables by checking issetugid(2).

To avoid this security hole, codes which compare setuid and
seteuid are used now, but not enough.  However, it is able to
avoid easily: ignore any environment variable in the locale stuff.


> 	- We have to consider how to extend FILE structure without
> 	  losing binary compatibilty.

Perhaps, we need not to take care of this problem, because of
the following reasons:
  - Most programs usually use FILE as the opaque handle.
  - To keep binary compatibility with MB_LEN_MAX, I have already separated
    setlocale into compatible one and new (renamed) one.
    Thus, when we will the wide-char I/O functions, we will be able to
    avoid this problem by the following way:
      - If the compatible version of setlocale function is called
        (or, setlocale is not called), fopen and others also work in
        the compatible mode.
      - If the new setlocale is called, I/O functions work in the new mode.


--
Takuya SHIOZAKI - Chair of IMOU.
The I18n/M17n project On Unix environments (IMOU), Japan.