From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
Using Canna through IIIMF, it lacks Canna dictionaries significantly.
When I restart htt_server manually as a user, it works correctly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fresh install FC2 everything
2. Run as Japanese user
3. Run gnome-terminal
4. Press Control-Space
5. Input 'mizumoto' and convert it
6. '水本' is not in the candidate
7. sudo /etc/init.d/IIim stop
8. Run /usr/sbin/htt_server as a user, not root
9. Input 'mizumoto' and convert it
7. correct candidate is in the candidate window
Actual Results: '水本' is not in the candidate window
Expected Results: '水本' is in the candidate window
Sorry Mizumoto-san, for using your name as the example.
But Fukushige-san has also same result.
Tagoh-san's name is fine.
Please look at
if htt_server is running as root (or the users who has some
privileges) or by yourself, it should works. but it seems to not
working somehow so that usually htt_server is running as a htt user
when it was realised by the init script.
BTW severity "high" means "Problem due to crashes, loss of data,
severe memory leak, etc.". this problem causes no crashes, no loss of
data, no memory leak. just missing the function which should works,
but there are a workaround.
*** Bug 125356 has been marked as a duplicate of this bug. ***
Running htt_server as root, it works. I've just now.
#125356 shows a workaround, but the problem is that there is no
chance for htt_server to refer $HOME/.canna . There's no workaround
for that, isn't it?
Current severity guide line does not refer i18n issues. If you don't
want it to be set as high, you should define the level for i18n issues.
And nowadays, customers specify 100,000 or more words in kana-kanji
dictionary for bidding, so the dictionary failure is severe problem
for all Japanese input users, even for open and free operating system.
It's unbelievable that Red Hat recognize this issue as lower severity.
No, it's not what I said for a workaround. as I said, it works if
htt_server is running as root/your user rather than a htt user. I
mean, Canna LE already has the code to refer $HOME/.canna. but
htt_server seems to need the privileges to fully support the multiple
I said, htt_server is running as a htt user right now. htt user has no
privileges. so htt_server gives LEs a htt user as current user. it's
also a reason why htt_server works if it's running as your user.
BTW severity is "normal". it's not lower severity, though.
LEIF has desktop data structure to handle mutliple user, but i think
Canna LE is not using it. This is an option, definitely not the best,
I will try to include Hideki into the loop and see if he has any idea.
Erm, Canna LE users it already. and it also uses setreuid(2) and
setregid(2) to change the real user/group and the effective usr/group.
since htt_server doesn't use fork(2), CannaLE may not uses it. it's
easy fix for Canna LE then.
However how about the library model's IM and it has the user specific
dictionaries?-- even if the current design of IIIMF isn't changed, the
server-client model's IM is possible to support the multiple users. it
depends on the implementation, though-- LEs needs to be run with
proper user. otherwise the library model's IM won't read/write the
dictionaries and their configurations securely.
htt_server has the authentication mechanism. but it's to connect to
htt_server, but not to support the multiple users on *LEs*. so
htt_server has to be run with the privileged user. otherwise IIIMF
will needs to be changed the security design and LEIF design. this
problem isn't Canna LE specific IMHO.
That problem should be discussed with the upstream anyway, though
- I wonder how this is on other ATOKX distros. It should have user
config with IIIMF. Running it as root, possibly.
- When user add new words to the canna dictionary through IIIM,
it would be going to add everybody's into the user htt's dictionary.
So it is supposed as everybody shares the htt's custom user dictionary.
Each user's dictionary should be treated as their own private data.
So it's critical. Currently, CannaLE has no codes to add new words so
this problem does not happen yet, but that will happen in the future.
- I think now I understand Anthy/UIM guys' critics against IIIMF.
The authors know the detail so I'm fine to wait the discussion in the
But I think they will answer that htt_server has enough security
for running as root:
- Default setting allows access from 127.0.0.1 only.
- LEs will lose root privilege at each startup.
- LEs need to run as each user.
I have another idea to fix this: Each users run htt_server.
That is stupid but effective.
Currently, many big processes are running as user. Bonobo, gconf,
nautilus, rhn-applet-gui, etc... So nothing happen with another new
Most of memory of htt_server is assumed as the conversion tables of
each LEs. So, to reduce memory size of htt_server,
- Don't load unecessary LE.
- bzip2-compressing the table data on the memory.
And it'll get much improvement
Or let htt server manage user specific information thru user htt, I
think this could an option.
Very good topic to talk in mailing list. Anyway, what does Sun do on
this problem? Do they run htt as root?
Hmm, ~/.canna is readable for anyone.
$ LANG=C ls -lga ~/.canna*
-rw-r--r-- 1 nakai 5542 May 25 16:16 /home/nakai/.canna
And users dictionaries too.
$ LANG=C ls -lga /var/lib/canna/dic/user/nakai/
-rw-rw-r-- 1 bin 54 Jun 1 18:28 #dics.dir
drwxrwxr-x 2 bin 4096 Jun 1 18:28 .
drwxr-xr-x 3 bin 4096 Jun 1 18:28 ..
-rw-rw-r-- 1 bin 79 Jun 1 18:28 dics.dir
-rw-rw-r-- 1 bin 0 Jun 1 18:28 usr1.ctd
So htt can read them. But Canna was developped when there is no
networks, then no security holes, or users' privacies. But users'
dictionaries are somewhat privates of users. Red Hat might need to
decide the policy which categorize them to. And this issue is not
Canna- or Japanese-specific, as you know.
How? as Nakai said, your idea should works for Canna, because it's
also the server-client model, and $HOME/.canna can be read from LE
even if htt_server is running as a htt user. But, it won't work
without the privileges on the library model like the dictionaries and
the configurations are put under $HOME as 0600 mode. so LEs has to be
run as the own user to prevent the security risk.
FC2's $HOME is 0700. Oh-no-
So there is no simple way to see it...
On all the other platforms, htt_server runs as root,
especially with ATOKX, which needs root previledge.
This shouldn't be a problem. In default htt_server only accepts
connection from localhost, and will soon be changed to use UNIX
domain socket in default.
The feature of user dictionary uploading/downloading from $HOME is
undergoing, so the problem of LE directly accessing $HOME will be
resolved soon in the proper way.
Also, the feature not ported between r10->r11, vmseparator is
planned to be backported to r12, so that LEs needing root
previledge can run beyond htt_server boundary which can run
as non-root user.
Running htt_server per user is also a valid option supported, for
whom wants to do so, as the developpers usually do so during
In r12, specific --user option is planned to be introduced for
such paranoia, but mostlikely this option is not needed for most
of the users.
Sorry, yes we are the
*** P A R A N O I A ***
So, yes we need the features...
Being paranoia for security is not a bad thing, and actually I am
too. There are bunch of common methods to improve security, so
many of them are implemented or in progress, but even before that,
we should accurately identify what's the root cause of the problem,
then design the solution for it, instead of jumping illogically
onto per-user library/server is the solution.
The cause of needing root previledge is not from IIIMF server
itself, but from some LEs(typically from the library linked by
it instead of the LE implementation itself). Some IM libraries
assume simple "getuid()" or such sort work always fine to get
user's identity. This assumtion forced to htt_server to run as
root, but the optimal solution is to fix such library. We have
vmseparator which could deal with such situation for some cases,
and also improve security and stability.
Note that any LEs directly accessing $HOME is NOT allowed (by
design :-). even though it is doable technically if server is
on local machine, but only client(and client libraries) should
have an access to $HOME.
So there is no need for IIIMF server/LEs to obtain root privilege
to access $HOME(by design :-).
interesting. on UNIX-like operating system, even vmseparator has to
obey that rules and the specification on the filesystems. and it
shouldn't assumes that the groups members and others can accesses to
the files. so how is LEs allowed to access to such files by
vmseparator without root privilege then?
and vmseparator works if the server and the client works on the same
machine, and it provides the facilities to access LEs to the $HOME
files indirectly, right? does it mean that vmseparator which is
running as another user processes the user-specific data? don't you
assume that there is no malicious users on the same machine?
There are several approaches to maintain so-called "privacy of
user dictionary". Even if a LE saves user dictionary same uid,
such as, say, "user canna" which is not readable by others, and
canna maintains the user as "canna user" instead of "UNIX user",
so-called "privacy of user dictionary" is maintained. This is not
at all surprisingly insecure approach, such as subversion is using
with svn+ssh method, for example.
About vmseparator; No, it's not what you imagined. Even via
vmseparator, No LEs should access $HOME directly comseptually :-).
The approach of vmseparator allows htt_server to use "UNIX user" by
running a separated LE instance in "real UNIX user id" to store
such private data in real UNIX user id. To do so,
in very small code to authenticate and change uid once to the target
user id portion still has to run with root privilege, but such
code only executes single extremelyl small static functionality,
so it would be much secure than having entire server running in
About malicious users; Of cource I assume there could be malicious
users on the same machine, but if such malicious user to take over
controll of what the LE instance beyond vmseparator stored, they
have to break the extremly small single function code to authenticate
and change uid, or they have to already obtain the target user's
UNIX id upfront. In the latter case, they already obtained the
access to wherever the user can, including $HOME anyway :-).
So I really don't buy the argument that storing users dictionary
into $HOME BY ITSELF significantly improves so-called "privacy of
user dictionary" as someone claims in loud.
Yes, right. I'm not saying that Canna's approach is secure.
For second comment, well, vmseparator will does something like ssh's
privilege separation, right? and LEs can accesses the files under
vmseparator needs the user authentication to allow the access. it
sounds good. so does IIIMF always ask people about their password to
allow the access? or is it stored somewhere?
For last comment, I thought all of data passes through vmseparator. as
you pointed out, I was misunderstanding. sorry.
So what I'm worry right now is only the path of the password. using
the plain text to authenticate it is worse you know. I would know your
opinion about it. if the path is secure, the malicious users may not
obtains the user.
I noticed that all comments are from committers :-), I guess
probablly as Leon suggested, we better move the discussion
to openi18n-im :-). Anyway, Akira, your comments on passwd
are very valid and fully agreed. The passwd will be stored
only in encripted form whenever it needs to be
stored.(Please don't be confused by FUD that IIIMF saves
passwd in plain text. What someone trumpeted is not a passwd
but a cookie created by a particular LE's helper process in
confusingly named file, but not by IIIMF).
About accessing user's dictionary in $HOME/, The proper
method will be to use the user data upload/download
mechanism(sorry, it's in progress yet. Hopefully be released
soon), instead of accessing directly $HOME from LE even with
vmseparator. So, for example, the code accessing
$HOME/.canna should be modified to use this mechanism
because htt_server and clients may run on different
machines, so accessing $HOME/ from htt_server. The libiiimcf
running in users UNIX ID will load $HOME/.canna on be half
I need to correct one thing :-O. After confirming with the LE
developper, it was inaccurate that I said
> (Please don't be confused by FUD that IIIMF saves
> passwd in plain text. What someone trumpeted is not a passwd
> but a cookie created by a particular LE's helper process in
> confusingly named file, but not by IIIMF)
Actually, noone is using it, but some experimental junk code is
creating such file. So it would be removed, and SSL based X.509
authentication will replace it.