Forum OpenACS Q&A: Comment on Documentation

Collapse
Posted by Richard Hamilton on
The new docs for installing OpenACS 5 are excellent however I thought of one issue while perusing them which I thought I should register.

The docs at:

https://openacs.org/doc/openacs-5-0-0/openacs.html

have a section which describes how to set up aolserver to run as the user 'servicename' so that there is no danger of having the system vulnerable if AOLServer is compromised.

I had this idea myself some time ago and tried to set it up but because I use nsunix I could not do it. The reason is that the proxy aolserver process writes the unix socket files quite rightly with a very restrictive set of permissions (to do otherwise would itself be a security risk). This means that the client aolserver process cannot communicate through the socket with the proxy process. If you try to manually set the permissions, because they are very temporary they get reset.

The new reverse proxy features of Aolserver 4 may be a different story but unless I missed a blindingly obvious solution I think that Jerry Asher's patched aolserver modules for nsunix will require all reverse proxied servers to run as the same user.

I hope that this will save people heartache and wasted time if they plan to use nsunix.

Regards
Richard

Collapse
Posted by Richard Hamilton on
Isn't it strange how the process of explaining a problem has a habit of solving it!

I was of course talking total nonsense. The reason that I couldn't get this to work was that I had misunderstood the format of the /etc/groups file.

So for anyone else trying to do this here is the snippet I missed.

Each individual entry in /etc/group consists of a single line having the following form:

group-name:x:GID:additional-users

The meanings of these fields are:

group-name: A name identifying the group. For example, a development group that is working on new simulation software might have the group-name simulation.

"!": The second field is the traditional group password field. It holds an exclamation point when a group password file is in use (see below), as is usually the case under Linux.

GID: This is the group's identification number. User groups generally start numbering at 100. Note that usernames and group names are independent of each other, even when the same name is both a username and a group name. Similarly, UIDs and GIDs sharing the same numerical value have absolutely no inherent, system-recognized relation to one another either, although the system administrator may choose to assign them in analogous ways).

additional users: This field lists all of the users and groups that will have access to this group's files in addition to those users belonging to the group by virtue of /etc/passwd. (These users do not need to be listed.) Note the correct syntax -- usernames must be separated by commas, but no spaces may appear within the list.

Here are some typical entries from an /etc/group file:

chem:x:200:root,williams,wong,jones
bio:x:300:root,chavez,harvey
genome:!:360:root

The first line defines the chem group. It assigns the group identification number (GID) 200 to this group. Linux will allow all members of group 200 plus the additional users williams, wong, jones, and root to access this group's files. The bio and genome groups are also defined, with GIDs of 300 and 360, respectively. Users chavez and harvey have access to the bio group's files, and root can access files of both groups.