DESIGN AND IMPLEMENTATION OF A WEB SERVER FOR A HOSTING
SERVICE
Daisuke Hara, Ryota Ozaki, Kazuki Hyoudou, and Yasuichi Nakayama Department of Computer Science
The University of Electro-Communications Chofu, Tokyo 182-8585 Japan email: [email protected]
ABSTRACT
A web server named Harache is presented. The server runs under the authority of the file owner. Existing servers have problems that occur because of the user authority during execution. When a program that uses a server embedded interpreter, for example PHP, creates data files, the owner of the created files is the special user account that runs a server. Therefore, other users that share the same server can steal and delete these data files. In particular, these prob-lems are serious for a hosting service where many users share a server. Harache has server processes that run un-der the authority of the file owner. Therefore, Harache can solve these problems that occur because of the user au-thority. Harache can be used for a hosting service where many people share a server with a reverse proxy. We im-plemented Harache on a Linux OS with SELinux and per-formed evaluation experiments to test the system’s effec-tiveness. Experimental results show that Harache has high performance and scalability.
KEY WORDS
Web and Internet Systems and Tools, Web Servers, User Authority, Privacy
1
Introduction
People are increasingly creating their own websites as the Internet grows in popularity. A hosting service, where many users share a server, is commonly used.
Existing servers have problems that occur because of the user authority during execution. Programs that are em-bedded in a server run under the authority of a special user account1that runs the server. When a PHP [1] program
cre-ates data files, the owner of the created files is the special user account. Therefore, other users that share the same server can steal and delete these data files. Also, when WebDAV [2] is used, the files’ owner is also the special user account. Actual file owners of an ordinary user ac-count typically cannot edit these files directly. In particu-lar, these problems are serious for a hosting service where many users share a server.
In order to combat these problems, we designed and
1apache, www-data, www, etc.
implemented the web server, Harache. Harache can be used for a hosting service where many people share a server with a reverse proxy. Harache has server processes that run under the authority of the file owner [3]. In this way, the owner of files that a PHP program and WebDAV create is each ordinary user account. Thus, other users that share the same server cannot steal and delete the data files of a PHP program. Also, ordinary users can directly edit files that are created by way of WebDAV. Therefore, Harache can solve problems that occur because of the user authority. We im-plemented Harache on a Linux OS with SELinux and per-formed evaluation experiments. Experimental results show that Harache has high performance and scalability.
The remainder of this paper is structured as follows. Section 2 describes the background of this work. Section 3 describes the key aspects of our design. Section 4 describes an overview of our implementation of Harache on a Linux OS. Section 5 presents an evaluation of Harache. Finally, Section 6 presents conclusions.
2
Background
This section describes the access control on a server and a hosting service. In this paper, “user” indicates a per-son who creates a website, and “user account” indicates the user account in the OS.
2.1 Access Control on Server
Existing servers run under the authority of the special user account (Figure 1). Although running under this authority improves security against outside attacks, it causes harmful effects for users in the server. First, users must grant read permission of publishing files to the special user account2.
That requires granting read permission to anotherwhich is different from anowneror agroup. Therefore, other users that share the same server can steal and execute these files regardless of the restricted access by way of the browser.
suEXEC [4] and POSIX ACL [5] were proposed to solve this problem. suEXEC executes a CGI under the au-thority of the file owner of the CGI. By using this module,
Figure 1. Overview of a request processing: existing server
the execution permission for an otherbecomes unnec-essary. Figure 2 shows the overview of CGI processing. Because suEXEC applies steps (2) and (3) in addition to normal CGI processing, overhead is caused. Additionally, suEXEC is not available for stealing text files. POSIX ACL is an access control mechanism at a filesystem level, and it offers control for every user account in addition to the ex-istingowner-group-otherpermission. By using this mechanism, the permission of read and execution needs to be granted to only the special user account.
However, foregoing mechanisms cannot ensure files are secure if the programs that are embedded in a server are used. WebDAV is an extension of the HTTP 1.1 and offers file management on a server from a client program, for example a browser. Also, PHP scripts are usually exe-cuted by the interpreter that is embedded in a server not as a CGI. Similarly, embedded interpreters are commonly used as an alternative for a CGI, such as mod perl [6], mod ruby [7] and mod python [8]. However, POSIX ACL has a lack of utility if the programs that are embedded in a server are used because PHP scripts can read published files of an other user if the read permission is granted to the spe-cial user account only. PHP scripts run under the authority of the special user account in the same way a server does. Thus, that means other users that share the same server can steal the published files of other users. Also, when a PHP program creates data files, the users must grant write per-mission to the special user account. Hence, other users that share the same server can steal and tamper with these data files.
This work provides an environment where server em-bedded programs can be used safely in a situation where many people share a server.
Figure 2. Overview of CGI processing
2.2 Hosting Service
Generally, networks with a reverse proxy are used for a hosting service applying load distribution. The procedure is as follows. First, requests are received by a proxy server at the frontend. Then, the proxy server redirects requests to the servers at the backend. Finally, the servers return the responses to clients. Actually, static files are cached at the frontend, and the frontend returns responses to the clients directly. Almost all of the redirected requests to the backend are for dynamic files such as a CGI. Throughput should improve by optimizing the servers at the backend in tune with an intended operation.
In the meantime, the biggest problem of hosting ser-vice providers is server footprints at the data center. It is important from a profit standpoint to house many users in a server.
The results of this work can be used for a hosting ser-vice where many people share a server with a reverse proxy. The mechanism gives priority to scalability of the number of users in the case of processing dynamic files such as a CGI.
3
Design
This section describes the design of a server we achieved, Harache. It can be used for UNIX-like OSes.
Figure 3. Overview of a request processing: Harache
3.1 Design Principle
We achieved the server, Harache, which solves problems that occur because of the user authority. As§2.1 described, existing servers have problems when server embedded pro-grams are used. Also, as§2.2 described, many users need to be housed in a server for a hosting service to make it profitable.
We designed a server that satisfies these requirements with a hosting service where up to 1,000 people share the server with a reverse proxy. One user account in Harache’s OS was assigned to each user of a hosting service. The de-sign principles of Harache are as follows. First, Harache executes server processes under the authority of the file owner, not as a special user account, to solve problems when server embedded programs are used. Second, it ter-minates unnecessary server processes when needed to im-prove scalability of the number of users. Third, Harache brings access control into operation with a secure OS [9, 10] to improve security against outside attacks.
3.2 Server
The authority of the server processes is changed to the file owner’s after Harache receives a request for user directo-ries. A user directory is where a user stores web content. Harache does normal processing after changing the author-ity. Figure 3 shows an overview of a request processing of Harache.
Harache terminates the server processes of users where no access occurs when needed. For UNIX-like OSes, a process occupies memory until its termination. As Harache has server processes for each user, each server cess only does one user’s operation. Hence, server pro-cesses for users where no access occurs can cause a mem-ory shortage. Harache solves this problem by terminating
the server processes of these users, thus achieving high scalability. Therefore, more users can be housed in the server.
3.3 Access Control on OS
Harache brings access control into operation with a secure OS. For UNIX-like OSes, the authority of the administra-tor account is required to change the authority of a pro-cess. Thus, Harache’s server processes start under the au-thority of the administrator account. Because server pro-cesses have been changed to the authority of the file owner when processing requests, starting under the authority of the administrator account is not dangerous. However, the authority of the administrator account in internet servers can be taken over because of a security hole and a miscon-figuration. Harache solves this problem by granting only the minimum authority to server processes. Therefore, the damage caused by taking over the authority of the admin-istrator account can be minimized.
4
Implementation
This section describes the implementation of Harache based on the design of the previous section. Harache was implemented on an Apache HTTP Server [11] (Apache) on a Linux OS with SELinux. The core of Harache was cre-ated as an Apache module, mod harache.
In the Linux OS, SELinux restricts the readable area of the server processes to the configuration files of Apache, and the writable area to the log files. It also restricts the executable area to the library directory for the Apache’s execution and the binary directory for the CGI’s execution. The read permission of the user directory is granted only to the directory owner. The write permission of the data directory of the CGIs is similarly granted only to the data directory owner. The details are as follows.
4.1 Server
We used Apache as the foundation for Harache. Apache accounts for about 70% of the servers on the Internet and is the de facto standard [12]. This implementation uses Apache HTTP Server ver. 1.3.33.
An Apache module, mod harache, is the core of Harache. It provides the functionality to change the author-ity of the server processes to the file owner’s. setuid() and setgid() system calls are used to change the authority. Actu-ally, mod harache creates a child process using a fork() sys-tem call before changing the authority. This child process changes its own authority and operates request processing. Then, the process is terminated after each session. Thus, it can prevent unaccessed server processes from causing memory shortage. Therefore, Harache is believed that it can achieve high scalability of the number of users.
Figure 4. Procedure for CGI processing of Harache
A CGI is not executed on Harache initially. A CGI is executed in Apache only when the user identity (UID) that was set in the configuration file (httpd.conf) is equal to the UID of the server process that operates the CGI processing. A CGI in Harache is not executed because the root is set in the httpd.conf, and server processes run under the authority of the file owner. To solve this problem, we assigned the UID of the server process that operates the CGI process-ing to the variable in Apache, ap user id, which holds the UID set in the httpd.conf. Therefore, Harache can execute a CGI.
In addition, mod cgi, which is included with Apache, creates a child process similar to mod harache for a CGI execution. Then, the process is created twice. This is wasteful. In order to solve this problem for CGI processing, mod harache does not create a child process and change its own authority. And, mod cgi changes its own authority. Figure 4 shows a procedure for Harache’s CGI process-ing. mod harache does steps (2)–(4) of the procedure, and mod cgi does step (6) in addition to steps (5), (7).
Also, server processes are changed to the authority of the special user account similar to Apache when it receives a request for somewhere other than a user directory.
5
Evaluation
In this section, we present the results of evaluation experi-ments with Harache. Table 1 shows the hardware configu-ration of the experimental environments.
Table 1. Hardware configuration of experimental environ-ments
Network
CentreCOM FS909GT V1 Switching Hub 1000 BASE-T port×1
100 BASE-TX port×8 Client
CPU Intel Pentium 4 1.6 GHz
Memory 512 MBytes
OS Fedora Core 2 (kernel 2.6.10) NIC DEC DECchip 21140 100 Mbps
Server
CPU Intel Pentium III Xeon 500 MHz×4
Memory 256 MBytes
OS Fedora Core 2 (kernel 2.6.10) NIC Intel PRO/1000XT PWLA8490XT 1 Gbps
5.1 Functional Evaluation
We performed functional evaluation experiments for Harache to determine that Harache has basic functions.
First, we performed an experiment to determine that Harache can create user websites while maintaining the pri-vacy and security in a server. We placed a text file, a CGI program file, and a PHP program file in a user directory A owned by user A. The owner of these files was user A. User A was the only one who could read, write, and exe-cute these files. Also, another PHP program file that steals these files was placed in user directory B owned by user B. We then logged in with user B’s account and found that user B could not steal and execute these files directly. Also, we attempted to browse another PHP program file that steals these files and found that these files could not be stolen. However, we were able to browse these files. This sub-stantiates that Harache can create websites but maintain the privacy and security in a server.
Second, we performed an experiment to determine if Harache can solve problems when server embedded pro-grams are used. We created a file in a user directory by way of WebDAV. Then, we determined that the owner of the created file was the same as the owner of the user di-rectory. Therefore, file operations can be done by way of WebDAV in combination with a direct login in Harache. In addition, we placed a PHP program file that creates a data file in a user directory and browsed it. Next, we deter-mined that the owner of the created data file was the same as the owner of the user directory. Therefore, other users that share the same server cannot steal and tamper with the data file because the permission forotheris unnecessary. This substantiates that Harache can solve problems when server embedded programs are used.
!"#$&%'(*)+ ,-. /01 -2 0 3 45 6 78 9 :<;=#> ?=!=#> :<;=#>A@CBD>FE*GHIGKJ
Figure 5. Basic performance evaluation: CGI
that Harache has the functions for which it was designed.
5.2 Basic Performance Evaluation
We evaluated the basic performance of Harache to deter-mine Harache’s usefulness.
An Apache HTTP Server ver. 1.3.33, which compiles by default, and an Apache HTTP Server ver. 1.3.33 with suEXEC were used for comparisons. Harache and the two Apaches used the configuration files by default. We used a httperf benchmark [13] to measure the performance.
We sent requests to a CGI file and measured the re-sponse throughput. The CGI is written in C and displays 10 KBytes characters. The results are shown in Figure 5. The X axis shows the request frequency, and the Y axis shows the throughput. Harache loses an average of 5.2% of the throughput relative to Apache. However, Harache achieves a high throughput relative to Apache with suEXEC. Thus, this implementation is effective. Also, the low throughput of Apache with suEXEC appears to occur due to an exter-nal wrapper program being used (setuid to root).
In addition, we sent requests to a text file and mea-sured the response throughput. The results are that Harache loses an average of 19.7% of throughput relative to Apache. However, its low throughput is improved substantially when networks with a reverse proxy are used because of their caching.
This basic performance experiment demonstrates that Harache achieves a useful level of performance.
5.3 Performance Comparison
We compared the performance of Harache with a compet-ing model to demonstrate the effectiveness of our approach. The One-to-one approach would be a competitor of Harache. One-to-one assigns a server for each user. Each server waits for a request at a unique port. One-to-one also uses networks with a reverse proxy. Thus, One-to-one has the same functions that Harache has without having to de-velop Apache modules if each backend server runs under the authority of its owner.
Table 2. Changed directives
Directive Name Default One-to-one Harache
StartServers 5 1 5 MinSpareServers 5 1 5 MaxSpareServers 10 1 50 MaxClients 150 150 256 ! "#%$&'(*)"# #,+-.0/ 123 4 5 6 27 5 8 9: ; <= > @? ? ACB D'E$ECC'
Figure 6. Experiment of performance comparison: CGI
We evaluated the performance of Harache and One-to-one. For the One-to-one system, we used an Apache that compiles by default. We changed the configuration for both systems as shown in Table 2. For the One-to-one system, we changed StartServers, MinSpareServers, and MaxSpareServers to run many Apache systems con-currently. For the Harache system, we changed MaxS-pareServers and MaxClients because Harache is at a per-formance disadvantage relative to One-to-one, which runs many Apache systems for all users from the beginning.
We sent 100 requests to a CGI file on each user’s web-site sequentially and measured the response throughput. The CGI is same as that described in§5.2, the one that dis-plays 10 KBytes characters. We used Apache HTTP server benchmarking tool ver. 2.0.41-dev included with Apache. The results are shown in Figure 6. The X axis shows the number of users in the server. For the One-to-one system, it is equal to the number of Apache systems. Also, the Y axis shows the throughput. Harache achieves substantially higher throughput than One-to-one from beginning to end. The throughput decrement in Harache due to an increase in the number of users is low.
This performance comparison demonstrates that Harache has an overwhelming advantage over One-to-one in scalability and performance. Therefore, this approach for developing Apache modules is effective.
5.4 Discussion of Approaches
Apache has a variety of ways in which it can be used. We described the normal use, Apache with suEXEC, and
Table 3. Comparison of approaches
Basic Performance (CGI) Scalability Solution of the User Authority Problems Availability
Apache ° ° × °
Apache with suEXEC 4 ° 4(only CGI) °
Apache2 with perchild - - 4(spec-level) ×
One-to-one 4 × ° °
Harache ° ° ° °
One-to-one. There is also an Apache HTTP Server ver. 2 with perchild [14]. Table 3 shows a comparison of ap-proaches. In the comparison items, “Scalability” represents that throughput decrement due to an increase in the num-ber of users is low. “Solution of the User Authority Prob-lems” represents that the problems described in§2.1 can be solved. “Availability” represents that the approach is avail-able now.
Normal Apache has problems that occur because of the user authority. Apache with suEXEC has low perfor-mance, and it has problems that occur because of the user authority during text processing and server embedded pro-grams. For Apache2 with perchild, the user account and group account that executes server processes can be set for each VirtualHost. Apache2 with perchild should have the same functions of Harache if the VirtualHost is assigned for each user. However, no reports show that perchild runs sta-bly, and it is not being developed now. One-to-one solves the problems that occur because of the user authority. How-ever, its performance and scalability are not very good.
Harache solves all of these problems while achieving high throughput and scalability. Therefore, this approach is the most effective.
6
Conclusions
We designed Harache, a web server that solves the prob-lems that occur because of the user authority, and we im-plemented it on a Linux OS with SELinux. We described the access control on a server and a hosting service and mentioned their problems. We performed evaluation exper-iments for Harache. The results demonstrated that Harache solves the problems that occur because of the user author-ity, that it has an advantage over other approaches in per-formance and scalability, and that it has a useful level of performance.
References
[1] PHP version 4,http://www.php.net/
[2] Y.Y. Goland and E.J. Whitehead Jr., HTTP Extensions for Distributed Authoring – WEBDAV, RFC 2518, 1999.
[3] D. Hara, K. Hyoudou, and Y. Nakayama, Implemen-tation and Evaluation of HTTP Server Operating with User Authority of File Owner, SEA Software Sympo-sium, pages 43–47, 2004 (in Japanese).
[4] Apache suEXEC Support,
http://httpd.apache.org/docs/suexec .html
[5] A. Grunbacher, POSIX Access Control Lists on Linux, FREENIX Track: 2003 USENIX Annual Tech-nical Conference, pages 259–272, 2003.
[6] mod perl,http://perl.apache.org/ [7] mod ruby,http://www.modruby.net/ [8] mod python,http://www.modpython.org/ [9] P. Loscocco and S. Smalley, Integrating Flexible
Sup-port for Security Policies into the Linux Operat-ing System, FREENIX Track: 2001 USENIX Annual Technical Conference, pages 29-40, 2001.
[10] Trusted Solaris Operating System,
http://www.sun.com/trustedsolaris/ [11] Apache HTTP Server,
http://httpd.apache.org/ [12] Netcraft, April 2005 Web Server Survey,
http://news.netcraft.com/, 2005.
[13] D. Mosberger and T. Jin, httperf—A Tool for Measur-ing Web Server Performance, 1st Workshop on Inter-net Server Performance, 1998.
[14] Apache MPM perchild,
http://httpd.apache.org/docs-2.0 /mod/perchild.html
