[Mailman-Users] problems with the config.db permissions

[Dan Mick]

> Check_perms fails to find it, and it's turning into a major problem.

Doublecheck your version of check_perms; the code is there, and it
works, in 2.0.5.  Are you running check_perms from the installed
bin/ directory as the instructions and about a billion posts on this
list say?
 
> What (exactly) writes and rewrites the config.db file and what are the actual
> permissions it's supposed to have? 

It should be owned by the user who writes it (which might be a lot
of places).  It should be group mailman, because the directory that it's
in should be group mailman, and have the "group-id bit" set so that
other file creations in that directory are also done by group mailman,
and also because all the programs that write it are themselves sgid-mailman.

In the case where you're updating things from the web page, the web server
run the CGI program, probably in your case as user "nobody"; the CGI program
validates the group it has been run as, and then sets its GID to mailman
before continuing.  That means all files it creates will be group mailman.

check_perms should be finding all this; you need to find out what's going
wrong with check_perms.

> From ealier reference it sounded as though
> it should be owned by nobody (since the webserver
> modifies/creates/backs-up/etc) and the group should be mailman. Ok - I can 
deal
> with this - but after manually setting the ownership to be just that - this is
> what I get after waiting a while and checking again:
> 
> [root at unica mailman]# ls -lR lists/|grep config.db
> -rw-rw----    1 nobody   mailman      9759 May  9 14:14 config.db
> -rw-rw----    1 nobody   mailman      9759 May  9 14:14 config.db.last
> -rw-rw----    1 nobody   mailman     16876 May  9 15:27 config.db
> -rw-rw----    1 nobody   mailman     16876 May  9 15:26 config.db.last
> -rw-rw----    1 nobody   mailman      2865 May  3 04:03 config.db
> -rw-rw----    1 nobody   mailman      2865 May  3 04:03 config.db.last
> -rw-rw----    1 nobody   mailman      3775 May  9 12:00 config.db
> -rw-rw----    1 nobody   mailman      3775 May  8 17:00 config.db.last
> -rw-rw----    1 nobody   mailman      5123 May  9 14:08 config.db
> -rw-rw----    1 nobody   mailman      5123 May  9 14:08 config.db.last
> -rw-rw----    1 nobody   mailman      3149 May  9 12:00 config.db
> -rw-rw----    1 nobody   mailman      3149 May  8 17:00 config.db.last
> 
> [root at unica mailman]# ls -lR lists/|grep config.db
> -rw-rw----    1 mailman  mail         9759 May  9 17:00 config.db
> -rw-rw----    1 nobody   mailman      9759 May  9 14:14 config.db.last
> -rw-rw----    1 mailman  mail        16876 May  9 17:00 config.db
> -rw-rw----    1 nobody   mailman     16876 May  9 15:27 config.db.last
> -rw-rw----    1 nobody   mailman      2865 May  3 04:03 config.db
> -rw-rw----    1 nobody   mailman      2865 May  3 04:03 config.db.last
> -rw-rw----    1 mailman  mail         3775 May  9 17:00 config.db
> -rw-rw----    1 nobody   mailman      3775 May  9 12:00 config.db.last
> -rw-rw----    1 mailman  mail         5123 May  9 17:00 config.db
> -rw-rw----    1 nobody   mailman      5123 May  9 14:08 config.db.last
> -rw-rw----    1 mailman  mail         3149 May  9 17:00 config.db
> -rw-rw----    1 nobody   mailman      3149 May  9 12:00 config.db.last
> 
> As you can see - the ones that get modified have their permissions changed to
> 'mailman:mail' and I've seen further changes where it becomes 'nobody:mail' 
and
> then mailman starts spitting errors out right and left and the lists just 
queue
> up messages and don't do anything anymore. Could someone please explain in
> detail exactly how it's /supposed/ to happen in a good situation?
> 
> <EOL>
> Tib
> 
> 
> ------------------------------------------------------
> Mailman-Users maillist  -  Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users