[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] bzr commit notifications

From: Glenn Morris
Subject: Re: [Savannah-hackers-public] bzr commit notifications
Date: Sat, 18 May 2013 14:00:27 -0400

(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 = address@hidden; touch /tmp/FOO

None of them succeeded in doing anything bad.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]