[Mailman-Developers] 2 Quickies

[Barry A. Warsaw]

>>>>> "JV" == John Viega <viega@list.org> writes:

    JV> BTW, I'm running redhat 5.1 too.  I've been thinking about
    JV> this problem, and I'm thinking that your problem is
    JV> potentially something like mailman files are getting created
    JV> as mailman.user instead of mailman.mailman, or something like
    JV> that.  That could cause problems.  I'd suggest making sure
    JV> that Mailman's /etc/passwd entry has the mailman GID in the
    JV> group field, and not the user GID.  Then you probably will
    JV> want to re-install.

But that shouldn't be happening, because I go to pains to install the
mailman directories with the group set-id (a.k.a. group sticky) bit
turned on.  Do an ls -l on $prefix/data an dyou should see something
like drwxrwsr-x.  The semantics are described like this in chmod(2) on
Solaris:

                    In a directory which has the set-group-ID bit
                    set  (reflected  as either -----s--- or -----
                    l--- in the output of 'ls  -ld'),  files  and
                    subdirectories  are created with the group-ID
                    of the parent directory-not that  of  current
                    process.

So all files created under $prefix/data should definitely be group
owned by mailman.  The INSTALL file says you must create $prefix with
the group sticky bit set, and chgrp it to mailman.  If you didn't do
this, then the groups on all the files will cascade to be incorrectly
group owned.  Do you think this is what happened?

It probably makes sense for either the configure script, or the
install target to explicitly check for this scenario.

-Barry