FAQ

Mark Sapiro wrote:

I think that was the problem, the directory owner. A digest went out at
noon and I no longer see the digest file in the list directory anymore.
We'll see what happens tomorrow.
If it succeeded in deleting the digest.mbox, you should be OK. I wonder
about changing the owner though. If that fixed it, maybe other
permissions are not right.

In my case the mailman/ and the mailman/lists directories are owned by
root and the mailman/lists/<listname> directory is owned by www if the
list is created via the web and by mailman if created by bin/newlist.
All the directories have permissions drwxrwsr-x

I think if group has rws, who the owner is is not important.

Does this agree with what you see?

--
Mark Sapiro <msapiro at value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
That is how my permissions are set, but apparently it did not like
having the owner of the directory as root. So when the sticky bit is
set on a directory that means only the owner of the file and directory
may remove the file. The owner was mailman, the owner of the directory
was root, and the sticky bit was set on the group. I guess this mixture
worked to prevent the mailman user from deleting the file.

After doing some testing this is what I have noticed.

Since the mailman account does not have a password I cannot log in as
the mailman account. The mailman account is not part of the mailman
group (is this a problem?). If I create a test directory, with
subdirectory and in that subdirectory put a file; then set the
permission as so:

topdir: rwxrwsr-x mailman.mailman
subdir: rwxrwsr-x root.mailman
file: rwxrwsr-x mailman.mailman

and I su - mailman from root it let me view and edit the file, but I
cannot delete the file. So, based upon me setting the wrong ownerships,
mailman did what it was supposed to do but could not delete the digest
file. That was my problem. Mailman was the owner of the file, but not
the directory so it could not delete the file.

Thanks for assistance.

Search Discussions

  • Mark Sapiro at Dec 7, 2004 at 7:52 pm

    Dann S. Washko wrote:
    That is how my permissions are set, but apparently it did not like
    having the owner of the directory as root. So when the sticky bit is
    set on a directory that means only the owner of the file and directory
    may remove the file. The owner was mailman, the owner of the directory
    was root, and the sticky bit was set on the group. I guess this mixture
    worked to prevent the mailman user from deleting the file.
    Well, changing the owner of the directory seems to have solved your
    problem and that's the bottom line.

    However, there are a few problems with the above. Despite what the
    manpage implies, the sticky bit on a directory usually means that
    either the owner of the directory OR the owner of a file in the
    directory can delete the file. Thus when a tmp/ directory has the
    sticky bit, I can create files there and delete my files, but only the
    owner of the tmp/ directory can delete other people's files.

    All this is moot however since the 's' in rwxrwsr-x is not the sticky
    bit, it is the setgid bit. The sticky bit would be the 't' in for
    example rwxrwxr-t.
    After doing some testing this is what I have noticed.

    Since the mailman account does not have a password I cannot log in as
    the mailman account. The mailman account is not part of the mailman
    group (is this a problem?).
    I think it's a problem. The INSTALL document says "The mailman user
    created in the previous step must be a member of this group." I'm not
    sure how things are working at all if this isn't the case.
    If I create a test directory, with
    subdirectory and in that subdirectory put a file; then set the
    permission as so:

    topdir: rwxrwsr-x mailman.mailman
    subdir: rwxrwsr-x root.mailman
    file: rwxrwsr-x mailman.mailman

    and I su - mailman from root it let me view and edit the file, but I
    cannot delete the file. So, based upon me setting the wrong ownerships,
    mailman did what it was supposed to do but could not delete the digest
    file. That was my problem. Mailman was the owner of the file, but not
    the directory so it could not delete the file.
    I think the issue here is the mailman user is not in the mailman group.
    The only thing that prevents the mailman user from deleting 'file' is
    the lack of write permission on 'subdir' because the mailman user is
    not root and is not in the mailman group. Actually, if the 'sticky'
    bit were set on subdir (rwxrwsr-t), I think mailman could delete file
    in this example. The only question is how did mailman create the file
    in the first place?

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedDec 7, '04 at 7:03p
activeDec 7, '04 at 7:52p
posts2
users2
websitelist.org

2 users in discussion

Dann S. Washko: 1 post Mark Sapiro: 1 post

People

Translate

site design / logo © 2022 Grokbase