(I'm not subscribed, please cc me) Bob Proulx wrote:
> My personal preference is to use the local command. I would use > /usr/sbin/sendmail as a general local mailer because that takes no > configuration. The external command is expected to behave like "mail", ie accept the -s and -a options. I think the internal smtplib method is preferable, eg because it gives nicer emails (diffs as an attachment rather than inline) and doesn't involve spawning an external process. In any case, that setting should be hard-coded once we figure out which works on Savannah. > Talking out the problem.... It would run on the server with the > user:group of the person who is running the commit, who is probably > not the person who set up the attack. The permissions would be similar > though. It would take quite a long time to traverse the entire > filesystem slowing things down for a long time. It would eventually > remove the project files that are accessible by that user:group. It > wouldn't have permission to remove other projects files or anything > else on the server. Worse would be if a single user were in several > groups because then it would have permission to remove all of the > files in all of the groups of that user. Oh, then maybe there is not much of an issue at all. I was assuming some member of project FOO gets their Savannah account compromised. Now the attacker can just delete project FOO without needing to do anything clever with post_commit_mailer, via normal bzr commands (of course, any other member of project FOO can push a fresh copy back again, so it's only a temporary inconvenience). Sounds like the only advantage they gain is that if someone else in FOO, who is also in other projects, makes a commit, they would maybe be able to delete those other projects too. Still, it's probably good to restrict the commands that can be run. I also checked things like trying to squeeze extra commands into option settings that might be passed to external commands. Eg: post_commit_diffoptions = -u ; touch /tmp/FOO post_commit_to = gm@localhost; touch /tmp/FOO None of them succeeded in doing anything bad.