Bug 125331
Summary: | htt_server needs the privileges to support the multiple users | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nakai <ynakai> |
Component: | im-sdk | Assignee: | Yu Shao <yshao> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | 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
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. *** 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 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. 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 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. 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. 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 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/ 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 #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. 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 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. Sorry, yes we are the *** P A R A N O I A *** for securities. 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 :-). 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? 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 #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. 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. 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.
|