From: Kimmo Suominen <kim@tac.nyc.ny.us>
Subject: Re: finger
Date: Wed, 11 Sep 2002 09:15:52 -0400
Message-ID: <20020911131552.9156F7E04@beowulf.gw.com>

> | OK, I have fixed it to conform to rfc1288 strictly in this point.
> | Thanks for your comment.
> 
> I think you are trying to implement the second switch from the RFC
> (print all characters), while I'm trying to implement the first one
> (print high characters) together with the environment option.
> 
> | BTW, your way doesn't ensure to conform to this recommendation strictly,
> | because of the principle of ISO C locale system.
> 
> What principle?  I seem to not understand why using isprint(3) is not
> acceptable.  Please elaborate.

isprint() is not hard-wired to ASCII.
Although our "LC_CTYPE=C" locale seems hard-wired to ASCII,
but this is just implementor's convenience.
By the principle of ISO C locale system,
we should not use ctype family function by the way depending on
any convenience of implementation or any specific codesets.
On the other hand, RFC1288 obviously depends on raw
character octet code.

# And, I don't admire nl_langinfo trick.
# This method lacks in pliability very much.


I think that at least the finger *server* complying with RFC1288
should not use isprint().  This server should simply work as:
  - by default, only 0x20-0x7E are allowed.
  - by optional, 0x80-0xFF are allowed.

c.f. section 2.2 of rfc1288.


> | While using ISO C locale system, we cannot touch any character code
> | directly, except for a few cases.  However, rfc1288 is hard-wired to
> | ASCII and mentions some concrete octet limits.  Thus, ISO C locale
> | system conflicts with rfc1288.
> 
> Finger was already using isprint(3).  Please explain why this is not
> a good approach?  I don't see why it would be preferable to define
> a separate set of similar functions inside each program.

Our finger is quite old program.
Although good-old-day's libc was hard-coded to ASCII,
the recent (ISO C compliant) libc is no longer so.
Our finger cannot only follow it.
Such an old custom is seen by other programs, but this is not good.
The program should not use them, if it needs to be dependent on
a codeset by a certain reason.


> I prefer a safe way of viewing 8bit data.  Your patch does not provide
> it at all.  Mine does.  Mine also does away with the alledged security
> problems with multi-byte character sets.
> 
> I also find it important to have an environment variable for enabling
> safe display of 8bit data.  LC_CTYPE/LANG are the natural way of doing
> that.

Surely, using isprint() is safer than simple 8bit through.
Your worry about finger client is also reasonable.
In this point, I made a concession by the past mail:

> OK, I suggest a solution:
>   - finger(1) never use ISO C locale system when it is called from fingerd.
>     Administrators can choose the one of two modes:
>       - ASCII only (default)
>       - 0x20-0xFF through (-8)
>   - standalone finger(1) can working the one of three modes:
>       - ASCII only (default)
>       - use ISO C locale for single byte locales (-i)
>       - 0x20-0xFF through (-8)

Of cource, an administrator may do

echo 'export LC_CTYPE=acme; alias finger="finger -i"' >> /etc/profile


--
Takuya SHIOZAKI