There are two levels of permissions to be concerned with: Unix filesystem permissions and web server permissions. In the filesystem, you only need to be concerned with use of chmod (and maybe chown and chgrp).
By the way, HyperNews does not store passwords of users in unencrypted form, to reduce risk of exposure. Instead, it only stores the encrypted form, and it checks a supplied password by encrypting it the same way and comparing to the stored encrypted password.
But there are ways to authenticate users while not requiring them to send any private information out to servers, such as a public/private key mechanism. We can't use such mechanisms yet because software is not widely available to users; the web is still growing support for doing security in these more reasonable ways.
Instead, we have four principal ways to authenticate in HyperNews: form-based, server-based, cookie-based, and external.
If you want to change the configuration of HyperNews from internal security to manual security, you need to run setup.pl from the command line at least once. The reason is that the .htaccess file is still present.
On the server, directories are typically restricted with a ".htaccess" file. HyperNews creates a single .htaccess file stored in the hnpeople directory, called .htgroupaccess. A symbolic link is made to this file from the SECURED, Admin, and .scripts directories, and from the HyperNews directory if all reading is restricted. For external security or manual security, the links to the .htaccess file are removed.
The .htaccess file references a password file, called .htpasswd, stored in the hnpeople directory, containing a list of userids paired with encrypted passwords. Other .htaccess files may reference the same .htpasswd file, but HyperNews wants to manage the contents of this file. The .htaccess file may also be used to perform access control, by referencing a file that associates group names with group members, but HyperNews no longer uses that mechanism (because servers tend to have bugs and large variance in this feature), and we were only checking membership in the group of all members or all administrators).
Notice that server-based authentication overrides form-based and cookie-based authentication in the sense that the server will request a userid and password from the browser regardless of their presense in forms or cookies. But once the server gets what it wants, HyperNews allows a separate userid and password to be provided in a form.
Cookies provide optional authentication because if they are sent by the browser, they can be used, but if not sent, form-based authentication can still be used if necessary. The userid and password provided by a Cookie is used with the lowest priority, since a browser will keep sending cookies even if a different user is using the browser.
Notice that external security is not the same as "internal" server-based authentication. If you want to make use of the server-based authentication mechanism that HyperNews sets up and manages, then don't use "external" security.
The .htaccess file, supported by several servers, can reference a list of groups of users who have access to particular operations, but this list of groups or the list of members in the group files might be long enough to overflow buffers in some servers. Furthermore, we only distinguish three kinds of users, non-members, members, and members who are also administrators. It is easy enough to have HyperNews check which kind of user we have, so that is what we do now. But when we support more groups of users, such as editors or moderators of particular forums, we will still probably do our own access control rather than relying on server mechanisms.
HyperNews identifies several kinds of actions and for each action, a different level of access control may be applied. These actions are things like Reading forums and messages, Writing messages, Creating or Editing forums. For each action, the HyperNews configuration specifies whether it may be performed by no one, anyone, members-only, or administrators-only. Administrators can generally do anything, even actions permitted by "no one", but the difference is whether there is any visible interface to access these actions.
Regardless of the configuration, HyperNews performs another kind of access control based on the URL used to access a script. If the URL contains '/SECURED/', then the user must be a member, and if it contains '/Admin/' or /.scripts/, the user must be an administrator. With that restriction, HyperNews sometimes changes the interface displyed to the user to enable some addition actions or display more information.
Some actions have data that will be affected and an owner of that data. For example, if the action is "delete a message", the author of a message is the owner, or the user who will be affected by the action. For each action, there is a hard-coded parameter used to specify what kind of user can be affected. For the example of deleting a message, the member doing the deletion must be the same member who owns the message. See access1 in member-lib.pl for the details.