DRAFT 6.2
1 February 1995
Nathan Bush,
nbush@uci.edu
Shohreh Bozorgmehri,
shohreh@uci.edu
University of California Irvine
Office of Academic Computing
Most current online copy kept at http://www.oac.uci.edu/X/W6/web-struc/web-struc.html
In the simplest case, all the documents available via a single web server come from a single source and none of the materials needs to be hidden from the users of that machine. In this case, using a single account to create web documents and making all of them world-readable allows them to be served over the web.
One significant drawback of this approach is that all the documents can be modified by any user with access to the single account being used and only by such a user. An obvious solution to this problem is to use separate accounts for different users or groups of users. This allows different individuals and groups to use a common server to distribute files provided that those files are readable by the server. In many cases, ``readable by the server'' can be adequately translated into ``readable by any user on the system.'' After all, the web server is going to publish the documents to the world. But web access to various documents and services can be limited by a variety of mechanisms, and one is still left with the question of limiting access to documents by other users of the system. Running web servers only on systems with severely restricted login bases is one way to approach this problem. Judicious structuring of the login accounts and groups is the approach this proposal outlines.
There are situations where it is not appropriate to have all web documents left world-readable. The documents may come from multiple, unrelated sources. The documents may contain sensitive information, and will need to be protected from access by other users on the machine. The web server may get the documents from a file system that is also exported to another networked machine, whose users should not have access to the information.
The solution is simplest when the documents only need to be protected from users not involved in their creation. A special group can be created that all information providers and the web server itself will share. The documents can be set to this group ownership, and will no longer need to be left world readable.
If information providers need to protect documents from each other, several groups can be created, one for each information provider. The server will need to belong to all of these groups. This method is most secure, but is limited by the number of distinct groups which the operating system allows any single user to belong to.
All of these situations can be addressed by creating special web information providing accounts and groups, and setting memberships and privileges appropriate to individual situations.
Information Providers are users who write, edit and maintain documents that are published through the web. There are two categories of information providers.
Individual information providers are users who make their own documents available through the web. Individual information providers can be added to the web using two different methods. The web server often allows for a special directory in every user's account that is automatically available. For web servers lacking this feature, a special directory can be created in the web server's document space, and individuals added with symbolic links pointing outside of the document space. All individual information providers are treated as a whole by the web server, so they will not be able to put special restrictions on their files. In the examples given below, the individual information providers are designated indiv.
Institutional information providers are users who provide institutional information through the web. Institutional information providers use special accounts (distinct from their personal use account) for placing documents into the web. Each such account may be used either by a single person or by several to promote collaborative work. In any case, all persons using this single account are treated as a unit. Files created by each institutional information provider will be protected from modification by others. Additional groups can be created to to protect files from access by other users of the system, while still allowing them to be served over the web. Because the web server pseudo-user (see below) must have access to all files to be served, the UNIX limit on the number of groups to which a single user can belong also limits the number of special information provider groups which can have materials served to the web but not readable by all all users on the system.
In the examples given below, the institutional information providers are designated ``winst*''. This is a shorthand for the class of logins belonging to specific institutional information providers. That is, winst* designates the class of logins that, in practice, might very well include such specific logins as the following: wphysics, wmath, wchem, wbio, wmed, wanthro, wfineart, whistory, wphilos, etc.
In this document, ``individual'' designates an ``individual information provider'' and ``information provider'' includes both individual and institutional information providers.
The web server itself must have access to all of the documents which can be made available via the web. In all other respects, it must be completely unprivileged. This is best accomplished by creating a special ``user'' (actually, a ``userid'' in strict UNIX-speak). This ``user'' isn't any individual or group of individuals, just a convenient/necessary mechanism. To call attention to this fact, we call it a ``pseudo-user.'' By the very nature of its role, this pseudo-user must be able to access all information which any information provider wants to make available via the web.
In the subsequent discussion and examples, the web server pseudo-user is designated w3serv and its login group is designated w3servg.
A Web Administrator is any one of the group of individuals responsible for maintaining the web server. This discussion assumes that all such individuals share access to a common login/userid which is called w3admin.
Via w3admin, web administrators handle web server configuration and installation, as well as web-related communication with those using the web server to publish/provide information/services. Thus, w3admin must have the same access to the files being served as w3serv and full write and update access to web configuration files. As a practical matter, it is not uncommon for w3admin to be an information provider for documents and services related to the administration of the server.
System administrators are the team responsible for administration of the machine, such as creating accounts or managing disks. While it is possible to run a web server without any involvement from system administrators, this prevents almost all of the structure features mentioned in this document. At a minimum, system administrators must be involved in creating the special accounts and groups, arranging for the web server to start automatically, and restarting it when configuration changes are made. While some overlap between the system administrators and the web administrators is not unusual, the roles are distinct.
In summary, we can consider the system administrators as managers of an office building in which an office manager (w3admin) establishes the conditions under which a distribution clerk (w3serv) responds to requests from clients by delivering information which individual and institutional information providers have authorized be released.
This structure provides for a central point of contact for all issues relating to the web server. It also clearly defines who is responsible for maintenance of the web server, and who is responsible for the information it contains.
This document outlines three alternative methods to implement Departmental Web Server Structure. In addition, it discuses the advantages and disadvantages of each strategy.
All three structures provide separate logins and some way of grouping to provide more security on Web space. In all methods, the web server runs as a special user account w3serv which delivers to web clients documents made available by information providers.
The first method describes the base (recommended) method. It limits the proliferation of groups by reliance on the w3pubg group to which the web server pseudo-user, w3serv, belongs.
Using this method, there are two disadvantages. An information provider either must allow ``world'' access to files being published or must set group ownership of such files to a group of which w3serv is a member (e.g., w3pubg). On the other hand, this may be an advantage - giving the information providers ability to ``publish'' documents only when necessary. Furthermore, because all documents belong to the same group, and all information providers are members of this group, all information providers have the ability to read all documents on the web server.
In second method (a more secure method), each information provider has a special account and belongs to a special group. People who maintain the web documents can share this account. The web server account must belong to all information provider groups in addition to its own primary group to make all documents accessible by the web server. Therefore, all documents can have ``640'' (owner-read-and-write, group-read) permission; a document needs to be readable only by group and not by others to be readable by the web server.
This way different information providers cannot access each other's documents. The only draw back would be the limitation on the number of groups that the web server can belong to. If the number of information providers grows then this method cannot be implemented.
The third method (the simplest method), does away with the special information provider groups entirely. All information providers belong to the same group and any group-readable file is accessible to all other information providers and access via the web server is limited only by server-dependent mechanisms.
The following provides a summary of implementation details for each method and it discusses their advantages and disadvantages.
In addition to whatever login group and other groups it belongs to, each information provider also belongs w3servg, the login group of the web server pseudo-user, w3serv.
This structure provides a fairly simple implementation which doesn't require w3serv to belong to more than one group. An information provider simply allows w3serv access to information to be published either by allowing ``world-readable'' access or by setting group ownership and readability so that a group to which w3serv belongs can access the information. While, setting access rights and group ownership may entail explicit actions by information providers, this may be considered a ``feature'' rather than a bother as it allows one to protect/hide documents until one is ready to publish them. Following shows three ways to change the document group:
chgrp w3pubg directory
chmod g+s directory
newgrp w3pubg
exit; exit to logout
alias pub-chgrp chgrp -R w3pubg documents...
NOTE: Users' home directories must have 750 permission for more security.
Login/Userid Groupid Extra group membership Home Shell Category ============ ======== ====================== ==== ===== ======================= w3admin w3pubg - yes yes Web Admin w3serv w3pubg - no no Server Pseudo winst* winst*g w3pubg ? yes Institut. Info Provider indiv* indiv*g - yes yes Indiv Info Prov
Ownership
File System userid.groupid Permissions
===================================== ============== ===========
WebRoot--+
+--ServerRoot w3admin.w3pubg 750
+--DocumentRoot--+ w3admin.w3pubg 755, 751
+--w3admin w3admin.w3pubg 750
+--winst* winst*.(1) 750
~indiv* indiv*.indiv*g 755
(1) Group is winst*g by default unless user explicitly changes this to w3pubg. Changing the group is necessary in order for w3serv to be able to access the document.
w3serv, the web server pseudo-user belongs to special, distinct groups to which different information providers also belong.
This method allows information providers to protect their documents against other information providers. However, one may well encounter limitations based on the number of distinct groups to which w3serv (the web server pseudo-user) and w3admin (the web adminstrator) can belong. drawback.
NOTE: This structure is most suitable for environments that require higher security and have limited number of information providers.
Login/Userid Groupid Extra group membership Home Shell Category ============ ======== ====================== ==== ===== ================== w3admin w3adming w3servg, winst*g yes yes Web Admin w3serv w3servg winst*g no no Server Pseudo winst* winst*g - ? yes Institut. Info Prov indiv* indiv*g - yes yes Indiv Info Prov
Ownership
File System userid.groupid Permissions
===================================== ================= ===========
WebRoot--+
+--ServerRoot w3admin.w3servg 750
+--DocumentRoot--+ w3admin.w3servg 755, 751
+--w3admin w3admin.w3servg 750
+--winst* winst*.winst*g 750
~indiv* indiv*.indiv*g 755
All information providers belong to web server group only and there are no information provider groups.
This is the simplest implementation solution and gives up the most security. By making all information providers members of a single group, their access is not protected from each other.
Login/Userid Groupid Extra group membership Home Shell Category ============ ======== ====================== ==== ===== ================= w3admin w3pubg - yes yes Web Admin w3serv w3pubg - no no Server Pseudo winst* w3pubg - ? yes Institut. Info Prov indiv* indiv*g - optional (1) yes yes Indiv Info Prov
(1) Ordinarily individual information providers do not have any special privileges, and all of their documents are left world readable. However, if an individual desires to publish documents securely, they can be given membership in the publisher group w3pubg. This allows them to act as a publisher account, without having to use any account other than their own.
Ownership
File System userid.groupid Permissions
===================================== ================= ===========
WebRoot--+
+--ServerRoot w3admin.w3pubg 750
+--DocumentRoot--+ w3admin.w3pubg 755, 751
+--w3admin w3admin.w3pubg 750
+--winst* winst*.w3pubg 750 (2)
~indiv* indiv*.indiv*g 755
(2) Information providers' home directories should have 700 permission for more security if they are located outside of the document space. Because all information providers belong to the same group, any other permission makes it possible to accidentally grant access to files in the publisher account to all other information providers. If the publisher account home directory is inside the document space, the permissions could be set to 710 or 750.
Another disadvantage of methods 1 and 3 is the way they handle Zot Dispatch Append. Group writability allows both w3serv and an information provider full access to the appended file, but allows this to all information providers! -- giving up significant amount of security. One solution is to create a special group w3writeg to which the information provider and w3serv belong. In addition, the group ID of the append file has to be w3writeg.
In conclusion, obtaining simpler implementation implies giving up some security. Departments should decide what method best fits their environment and needs.
This chart lists several activities that are part of web server operation. It indicates which users perform each activity and the permissions required for each.
Activity root w3admin w3serv winst* indiv ======== ======== ======== ======== ======== ======== start/restart server * - - - - alter server cfg/bin * * - - - read server cfg/bin * * * - - add dirs in web * + - + - add docs in web * + - + - read docs in web * * * + + chown * - - - - chgrp/chmod * + - + +