problem with the openwall kernel patch and mailman

Traceback (innermost last): File "/var/mailman/cron/checkdbs", line 87, in ? main() File "/var/mailman/cron/checkdbs", line 41, in main mlist = MailList.MailList(name) File "/var/mailman/Mailman/MailList.py", line 69, in __init__ self.Load() File "/var/mailman/Mailman/MailList.py", line 858, in Load self.Lock() File "/var/mailman/Mailman/MailList.py", line 1300, in Lock self.__lock.lock() File "/var/mailman/Mailman/LockFile.py", line 209, in lock os.link(self.__lockfile, self.__tmpfname) OSError: [Errno 1] Operation not permitted
this error i get in the checkdb and senddigests programs
the errors started appearing after i upgraded to 2.2.15-ow1
on of the ow1 patches security enhancing functions is restricting who can own what in +t directories
snipped from ow1's README file:
Restricted links in /tmp
I've also added a link-in-+t restriction, originally for Linux 2.0 only, by Andrew Tridgell. I've updated it to prevent from using a hard link in an attack instead, by not allowing regular users to create hard links to files they don't own. This is usually the desired behavior anyway, since otherwise users couldn't remove such links they've just created in a +t directory, and because of disk quotas.
Restricted FIFOs in /tmp
In addition to restricting links, you might also want to restrict writes into untrusted FIFOs (named pipes), to make data spoofing attacks harder. Enabling this option disallows writing into FIFOs not owned by the user in +t directories, unless the owner is the same as that of the directory or the FIFO is opened without the O_CREAT flag. ---- END SNIP ----
does anyone know if this would be hard to fix in mailman?
Andreas
participants (1)
-
Andreas Marienborg