Jonas Meurer writes:
Good question. Two options come into my mind:
- Provide a sudoers include file and make the mailmman command use sudo to run the actual commands as user mailman/list/whatever.
I would oppose this strongly. The problem occurs only file creation time; we should not provide more privileges than necessary whether via sudo or suid.
- Check if the command is run under expected UID/GID and error out if not.
This would be acceptable.
Probably a commandline argument to ignore this check would be required in that case.
If useful, this would be just as bad as the current circumstance. Who would remember that option exists?
I don't consider either of those solutions particularly clean. But it's a matter of fact that people will run mailman commands as user root, which results in logfiles, list files, etc. being created with owner root. Which in turn leads to errors since the mailman daemon is unable to further write to those files.
If permissions on Mailman-created files is the problem, the short-run response is "I guess you got root? fix it yourself." :-/
In the longer-run, creating those files with the appropriate ownership should solve the problem, since writing to an existing file doesn't change its ownership. This can be done at installation (and may require alteration to Mailman and/or log-rotation utilities to not (re)move such files, but rather to copy and truncate them).
Another possibility would be to set appropriate ownership and the suid bit on the appropriate directories (though this would not necessarily provide the appropriate group, I don't know if that's an issue). This is probably the most straightforward fix in terms of code, as well.
Steve