Note: The patch described in this file has been implemented, but is disabled by default. To enable it, change #define SLRNPULL_USE_SETGID_POSTS 0 to #define SLRNPULL_USE_SETGID_POSTS 1 in slrnfeat.h, and recompile. The patch is from Sylvain Robitaille , and is described below: --------------------------------------------------------------------------- This patch will allow you to run slrnpull as an unprivileged user, rather than as root, (or as yourself). To do this (if you're already using slrnpull), you'll need change the ownerships of all the directories and files from your SLRNPULL_ROOT_DIR and down. ie: # chown -R news.news /local/var/slrnpull Use whatever user name, group name, and path appropriate for your own system. Run slrnpull from the news user's crontab, rather than from root's (or your own). Note that this has been tested on Linux-2.0.xx, but should work fine on any Unix I've seen. It relies simply on the fact that a setgid directory forces all files placed within that directory to be owned by the group owner of the directory. Please post questions, comments, or criticisms to the newsgroup. # 1998/07/07 Sylvain Robitaille: Patch to allow slrnpull to run with # reduced privileges. # # Background: Slrn runs with a umask of 077, as set in src/slrn.c. This # means that any files created by slrn on behalf of a user # are readable and writable only to that user. Normally, # this is the desired result. # # Unfortunately, it also means that out-going posts created # in the slrnpull/out.going directory are also created with # the same file modes. This means that for slrnpull to be # able to remove the file from the out.going directory after # it's been posted, (or move it to the out.going/rejects # directory if posting failed), slrnpull must either be run # by the same user that posted the message, or by root. On a # multi-user system, the latter is the only option. # # For a variety of reasons, programs should only run as root # if they need the extra privilege. In this case, all that # was needed was to give slrnpull enough privilege to # manipulate files created in the out.going directory. # # Solution: Create a special user and group id for slrnpull. I've chosen # to name them both 'news', (but any name will work just as # well). The only group the news user belongs to is the group # 'news'. The entire directory tree where slrnpull works is # owned by user 'news' and group 'news'. Slrnpull is run from # user 'news' crontab file. # # This permits slrnpull to run without root privilege, and # still have all the permissions it needs to work within the # news spool and associated log files. The tricky part is that # now, slrnpull can't manipulate local posts in the out.going # directory, because the files are owned by the user/group # that created them with read/write permission only to the # user. # # If we make the out.going directory setgid to the group # 'news', files created in that directory will be owned by # that group. We now only need to provide read/write # permission to user *and* group at the time the file is # created. # # This patch does exactly that. It also patches slrnpull to # create the out.going directory with the setgid bit.