[Bug 599066] Create a specific check for the gnomeweb user from l10n.gnome.org

["sysadmin" (bugzilla.gnome.org) <bugzilla gnome org>]

https://bugzilla.gnome.org/show_bug.cgi?id=599066
  sysadmin | Git | unspecified

--- Comment #18 from Jeff Schroeder <jeffschroeder computer org> 2010-10-29 21:14:54 UTC ---
(In reply to comment #17)
> (In reply to comment #8)
> > Ok so here is the plan of attack...
> > 
> > 1.) Setup a password-less ssh key for gnomeweb l10n gnome org  Make the private
> > key readable by the gnomeweb _user_ only and not the group. l10n.gnome.org has
> > fairly limited user access as is so the attack vector is lower than many other
> > servers.
> 
> Is damned lies really running as gnomeweb? Thought we pretty much gave up on
> running web services under a non-apache user.

We run django apps as user gnomeweb. mod_wsgi is very flexible and gives
advantages to running things this way. The tomboy online webapp, snowy, runs as
gnomeweb as well.

> Basically if you have commit access to l10n.gnome.org you can make the account
> do whatever you want, so I don't think locking down the key too hard has a
> point. Readable-as-web-service-user seems about as good as we can easily do.

Ok so the question is do we wand d-l to run the equivalent of git push directly
to git.gnome.org? It does open things up a bit more, but in the worst possible
case, someone reverts the commits and it is only language files. You seem to be
of the opinion that it is ok to give users enough rope to hang themselves. I'm
still working out the details of how things in gnome-land work :)

> > 2.) Have create-auth[1] throw down a special ssh key[2] for the gnomeweb user
> > including the host="boron.canonical.com,91.189.93.2" line when given the
> > --gnomeweb-hack argument. This restricts ssh connections from that ssh key to
> > only originate from l10n.gnome.org aka progress.gnome.org aka
> > boron.canonical.com. 
> > 
> > The patch to do this is attached. Owen or someone else on the sysadmin team
> > please review it to let me know if this is the right idea. create-auth is going
> > to get a lot of love later on. Splinter is truncating the full length of the
> > patch in my browser so look at it raw.
> 
> See separate review.

I agree with almost all of it, but can't respond indepth or do anything about
it until later tomorrow or this weekend. That whole "real life" thing.

> > 3.) On l10n.gnome.org, configure the git global user (and the d-l process that
> > commits) to be "Damned-Lies Autocommit", and the global git client email to a
> > mailinglist that emails all of the translators (if that list exists). This is
> > for reply to go to the main l10n email list if someone wants to reply to an
> > auto-checkin.
> 
> I think noreply gnome org would be better. (Check that that's what we use for
> bugzilla mail, etc.) Mail aliases imply accountability for responses. Also, I
> would make the name something meaningful - Damned-Lies is an implementation
> detail.

That is all arbitrary and subject to change.

> > 4.) Write a simple bourne shell git hook that runs these checks:
> >    a.) [ "$(/usr/bin/whoami)" = "gnomeweb" ]
> >    b.) [ "$(/usr/bin/id -u)"  = "2184" ]
> >    c.) [ "$committer_name"  = "Damned-Lies Autocommit" ]
> >    d.) [ "$committer_email" = "the email for the main l10n list" ]
> >    e.) If it works[2], logic similar to Claude's pseudocode would be perfect.
> > 
> > I double-checked that whoami runs geteuid(2) (yay strace) so b isn't 100%
> > necessary. The goal is max paranoia and gracefully die if anything is off. c
> > and d are easy for anyone to circumvent with "git commit --author", but they
> > are just an extra layer of sanity checking. e is to make sure that only
> > translation files are being committed.
> 
> Hmmm, not really a fan of belt-and-suspenders-and-duct-tape. Adding easily
> circumventable checks just adds potential breakage without security. I'd do a
> single check that we are confident in. /usr/bin/whoami = <translation user>
> seems good enough to me. If you can subvert that, you can subvert the operation
> of the shell script and the system to the point where that single check working
> doesn't matter.

History and smart people like Dan Walsh and Bruce Schneier have taught me
security works best in layers. However, I'm still fairly new to how we handle
things so this list will be shortened to a and e.

> > 5.) Teach d-l how to commit translations to a local git repository and rebase
> > ontop of changes (hello git.py). The sysadmin team will write a cronjob to
> > periodically push commits to git.gnome.org as user gnomeweb. I'll address
> > points 1-3 now and put this off to someone else until at very least after the
> > Boston Summit.
> 
> This part is all up to the damned lies maintainers - though that they already
> had code. Transifex certainly does.

Claude seems to be of the opinion d-l should do that. If you're ok with it, I'm
ok with it.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the QA contact of the bug.
You are watching the assignee of the bug.