Barry Finkel wrote:

I have on my Mailman 2.1.10 production system and my 2.1.11 test system both created from the SourceForge source and installed on Ubuntu dapper via packages I built:

mailman% ls -al /var/lib/mailman total 40 drwxrwsr-x 10 root list 4096 2007-02-28 11:11 . drwxr-xr-x 22 root root 4096 2008-04-04 13:31 .. lrwxrwxrwx 1 root root 20 2008-06-30 16:13 bin -> /usr/lib/mailman/bin lrwxrwxrwx 1 root root 21 2008-06-30 16:13 cron -> /usr/lib/mailman/cron lrwxrwxrwx 1 root root 24 2008-06-30 16:13 Mailman -> /usr/lib/mailman/Mailman lrwxrwxrwx 1 root root 24 2008-06-30 16:13 scripts -> /usr/lib/mailman/scripts <<Non-relevant lines from the "ls -al" listing have been removed.>> mailman% mailman# ls -al /usr/lib/mailman total 36 drwxr-xr-x 7 root list 4096 2007-02-28 11:11 . drwxr-xr-x 48 root root 12288 2008-06-09 12:24 .. drwxr-xr-x 2 root list 4096 2008-07-23 14:55 bin drwxr-xr-x 2 root list 4096 2008-07-23 14:55 cron drwxrwsr-x 2 root list 4096 2008-07-23 14:55 mail drwxr-xr-x 11 root list 4096 2008-07-23 14:55 Mailman drwxr-xr-x 2 root list 4096 2008-07-23 14:55 scripts mailman#

When I run check_perms it complains:

mailman# check_perms
directory permissions must be 02775: /var/lib/mailman/Mailman
directory permissions must be 02775: /var/lib/mailman/bin
directory permissions must be 02775: /var/lib/mailman/cron
directory permissions must be 02775: /var/lib/mailman/scripts
Problems found: 4
Re-run as list (or root) with -f flag to fix
mailman# 

As Mailman is running fine, I do not want to change the permissions on the symbolic links. Is this correct? I have 755 for the permissions on the real files to which the symbolic links point.

You can't change the permissions on a symlink itself anyway. Any attempt to do so will attempt to change the target.

Is check_perms reporting on the permissions of the symlinks or the permissions of the real files to which the symbolic links point?

The targets.

What problems would I see if I do not have group write not "02" on these four files?

Typically these directories are SETGID and group writable. The fact that they are not SETGID means that anything created subordinate to them will be created with the group of the creator and not the 'list' group. In practice the contents of these 4 directories are normally only read, so as long as everything is world readable, it will work.

But if you applied a patch to some .py file in the Mailman directory, Mailman processes running as group 'list' might not have permission to update the corresponding .pyc file.

I have to wonder why you are doing this with symlinks at all. It looks like what you really want is to run configure with

--prefix=/usr/lib/mailman (the default), and --with-var-prefix=/var/lib/mailman

or something similar.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan