Graham Dumpleton wrote: > 2009/4/8 KaiGai Kohei <kai...@ak.jp.nec.com>: >> Graham Dumpleton wrote: >>> 2009/4/8 KaiGai Kohei <kai...@ak.jp.nec.com>: >>>> KaiGai Kohei wrote: >>>>> Graham Dumpleton wrote: >>>>>> 2009/4/8 KaiGai Kohei <kai...@ak.jp.nec.com>: >>>>>>> Graham Dumpleton wrote: >>>>>>>> Explain first why using FASTCGI and suexec wouldn't be a better option? >>>>>>> Thease are limited to cgi applications, so we cannot apply such kind >>>>>>> of restriction on the built-in script languages and references on >>>>>>> static documents (like *.html). >>>>>> FASTCGI is not restricted to CGI applications. At least in the sense >>>>>> that FASTCGI allows persistent processes rather than one off processes >>>>>> like CGI. FASTCGI bindings are available for many different languages, >>>>>> including scripting languages, so what 'built-in script languages' are >>>>>> you talking about? The suexec mechanism comes into play as it allows >>>>>> FASTCGI processes to run as a different user than Apache process. >>>>> Hmm... I'll try to search for more details of features of FastCGI. >>>>> >>>>> If you have a hint, could you tell for the questions currently I have? >>>>> IIRC, the CGI version of PHP cannot handle applications which write >>>>> out special HTTP headers, such as WWW-Authenticate: or Location:. >>>>> Is it possible to handle correctly in FastCGI? >>>>> I could not find FastCGI support for WebDav. Is it possible to control >>>>> accesses on files using SELinux? >>>> Hmm... It seems to me FastCGI has same limitation. >>>> The online document introduces that an authenticator program can >>>> be performed to handle authentication phase, but it may require >>>> web applications to be modified. >>>> http://fastcgi.coremail.cn/configuration.htm#Authenticator >>>> >>>> If we don't hesitate to create a new process for each requests, >>>> I have one another idea which does not require new hooks. >>>> In the traditional client-server model, the server process forks >>>> a child process to handle a request come from clients. >>>> If we have such kind of MPM module, a security module can set >>>> an individual privilege at the head of ap_run_handler hook. >>>> >>>> Needless to say, it has performance tradeoff, but we assume users >>>> don't give the highest priority on the performance. >>> See experimental MPM from Apache 2.0. >>> >>> http://httpd.apache.org/docs/2.0/mod/perchild.html >>> >>> Didn't get carried through to later Apache versions. >> If I can understand correctly, the perchild mpm assigns individual >> userid per virtual host, so it means all the requests handled by >> a certain virtual host shares same privilege set. >> The purpose of my efforts is to set individual privileges for each >> web users of the given request. >> >> Thanks for your information, but it is not suitable for us... > > Rather than you say what changes you think need to be done at low > level that you actually explain better at a high level what you are > trying to do. It is really hard to respond to you when we have no real > idea of the outcome you are trying to achieve.
Hmm... I've misunderstood that a discussion in abstracted-level does not interest folks, because nobody replied to previous messages. I also agree to rewind the discussion at the high level design what I would like to resolve, needless to say. > Specifically, what Apache modules are you trying to use that you > specifically want requests to be handled as separate users. You > mentioned 'built in scripting languages' before, but when I asked you > what scripting languages, you didn't answer. It contains something like mod_php, mod_perl and so on. Indeed, FastCGI can support to execute scripts written in them. In addition, I would like not to forget a path to access static documents like *.html, *.pdf and others. When a web system is set up to associate a security context with http-authenticated users, we would like to apply consistent access control rules independent from the way to access. For example, if a privilege associated with web-user: kaigai is not sufficient to access pdf files labeled as "classified", it should not be allowed even if web-application (launched by "kaigai") tries to access them, or even if the "kaigai" tries to access with a url such as: http://..../path/to/file.pdf directly. > As I have already pointed > out, if you are trying to provide scripting language support for > writing Python web applications then FASTCGI can be used, but then you > have dismissed that based on authentication reasons but not really > explaining what the problem is. In my preference, I would like to run existing web-applications without modifications as far as possible. Some of them assumes *.php scripts are run on mod_php.so, thus we often need to modify them to work on CGI version, for example. It is not a preferable for us. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com>
