Bug 125331

Summary: htt_server needs the privileges to support the multiple users
Product: [Fedora] Fedora Reporter: Nakai <ynakai>
Component: im-sdkAssignee: Yu Shao <yshao>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: eng-i18n-bugs, fedora-ja-list, khirano, mkhatto
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-11 06:08:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 125997    

Description Nakai 2004-06-04 19:30:43 UTC
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):
im-sdk-11.4-43

How reproducible:
Always

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. '&#27700;&#26412;' 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:  '&#27700;&#26412;' is not in the candidate window

Expected Results:  '&#27700;&#26412;' is in the candidate window

Additional info:

Sorry Mizumoto-san, for using your name as the example.
But Fukushige-san has also same result.

Tagoh-san's name is fine.

Comment 1 Akira TAGOH 2004-06-07 06:20:49 UTC
Please look at
http://www.redhat.com/archives/fedora-i18n-list/2004-May/msg00024.html

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.

Comment 2 Akira TAGOH 2004-06-07 06:21:54 UTC
*** Bug 125356 has been marked as a duplicate of this bug. ***

Comment 3 Nakai 2004-06-07 08:37:09 UTC
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.

Comment 4 Akira TAGOH 2004-06-08 03:06:38 UTC
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
users.
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.

Comment 5 Yu Shao 2004-06-08 13:15:21 UTC
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.

Comment 6 Akira TAGOH 2004-06-09 08:13:47 UTC
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

Comment 7 Nakai 2004-06-09 17:20:46 UTC
Some thought:

- I wonder how this is on other ATOKX distros. It should have user
specific
  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.

Comment 8 Nakai 2004-06-09 17:54:00 UTC
The authors know the detail so I'm fine to wait the discussion in the
upstream.

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.


Comment 9 Nakai 2004-06-09 18:24:50 UTC
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
service process.

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

Comment 10 Yu Shao 2004-06-10 00:01:12 UTC
Or let htt server manage user specific information thru user htt, I
think this could an option.

Comment 11 Leon Ho 2004-06-10 00:18:46 UTC
Very good topic to talk in mailing list. Anyway, what does Sun do on
this problem? Do they run htt as root?

Comment 12 Nakai 2004-06-10 05:53:29 UTC
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/
total 16
-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.

Comment 13 Akira TAGOH 2004-06-10 09:23:32 UTC
Comment #10:
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.

Comment 14 Nakai 2004-06-10 11:56:06 UTC
FC2's $HOME is 0700. Oh-no-
So there is no simple way to see it...

Comment 15 Hideki Hiura 2004-06-12 20:54:37 UTC
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
development.
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.

Comment 16 Nakai 2004-06-13 15:27:28 UTC
Sorry, yes we are the

***    P    A    R    A    N    O    I    A   ***

for securities.

Comment 17 Nakai 2004-06-13 15:28:07 UTC
So, yes we need the features...

Comment 18 Hideki Hiura 2004-06-13 19:15:17 UTC
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 :-).





Comment 19 Akira TAGOH 2004-06-14 00:53:02 UTC
Comment #18:
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?


Comment 20 Hideki Hiura 2004-06-14 05:32:07 UTC
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
root privilege.
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. 

Comment 21 Akira TAGOH 2004-06-14 08:08:57 UTC
Comment #20:
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
$HOME then?
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.

Comment 22 Hideki Hiura 2004-06-15 18:05:42 UTC
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
of CannaLE.

Comment 23 Hideki Hiura 2004-06-16 10:05:20 UTC
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.