Re: [Savannah-hackers-public] [sr #107077] Setting up bzr+ssh on Savannah.

[Karl Fogel]

Sylvain Beucler <address@hidden> writes:
>I won't be at Libre Planet, so discussion will probably remain on this
>list.
>
>- My main critic is that you're designing a system from scratch, but
>the goal is to integrate it well at Savannah.

Yes.  I didn't realize I could use SFTP to explore the entire
bzr.sv.gnu.org filesystem, including areas outside the Bazaar shared
repository.  If I had known that, I would have approached this very
differently!  (I don't have any kind of shell access.)

Now that I know, I will repost a recipe based on the existing situation.

>- Most of your setup sounds good, and it's pretty to close to what's
>currently installed (consider that bzr+ssh had been running in the
>past, before we switched to SFTP).  I suggest you take a look at
>sftp://bzr.sv.gnu.org:/ , browse around and explain what needs to be
>changed.  I can also provide root access which would be easier: who's
>gonna maintain the changes?

Who is going to maintain Bazaar access in general?  I'm happy to help.
I can't commit to general maintainance forever, but then again, anyone
who does commit to that is probably fooling themselves.

>- I don't understand the roal of a 'bzrusers' group.

Bazaar would be running as the user who SSH'd in, yet Bazaar needs write
access to the branches.  Hence, a group.  (Again, may not be necessary
now -- I'm just explaining the role of the group in my original proposal.)

>- Shell restriction is better done with a restricted shell, rather
>than using 'command='.  Check /usr/local/bin/sv_membersh.

Looking at it now.

>- Plugins:
>
>The basic security principles at Savannah are:
>
>* sysadmins determine what commands the user can run (so they have no
>  chance of running a custom exploit)
>
>* security still needs to be solid if the user gets local access
>
>* we consider 4 levels of access:
>  1. restricted shell
>  2. restricted shell + filesystem-level access
>  3. local access
>  4. root
>
>  No escalation should happen.

These four levels say nothing about read-only vs read-write.
Does (2) mean filesystem-level read-only access, or read-write?
Does (3) mean a shell login with read-write access?

(I don't think I need to know the answers to design a good Bzr commit
access system.  I'm just asking so I can clarify my general Savannah
admin knowledge.)

>Bzr is typically a candidate to move to "no-SFTP" depending on what it
>does with plugins.  You recently explained that only system-wide
>(/usr/lib/.../plugins) plugins should be able to run; however there's
>still a grey area about: a) ~jrandom/.bazaar/plugins and b) user
>plugins configuration.  Can you detail what these permits, in
>particular in the light of the access levels I described?

As discussed with Robert, moving to no-SFTP is probably what we want to
do.

As for plugins, there should be no grey area.  What I said before
remains true: ~jrandom/.bazaar/plugins should remain unwriteable by
jrandom.

>- commit mail notifications: can you detail what options we have to
>run commit mail notifications?  Typically CVS/SVN/Git/Hg use commit
>hooks, bzr currently uses 1 cronjob per branch which I'm not sure
>would scale (but I might be wrong).  Do you see alternatives?

I'll look into it.  I found the cron job in /etc/cron.hourly/.
By the way, we have some old bzr cron cruft lying around in:

  /etc/cron.d/bzr_commit_mail_notification.bak
  /etc/cron.d/bzr_commit_mail_notification.bak2

Can those two be removed?  And is all this configuration under version
control, in general?

-Karl