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

[Sylvain Beucler]

Hi,

On Wed, Mar 17, 2010 at 12:59:22PM -0400, Karl Fogel wrote:
> >- 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.

The system will generally be maintained as it currently is, but we do
need your help, that is, somebody more involved with Bzr and willing
to tweak and improve its installation.


> >- 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.)

There's a unix group per Savannah project, which I think fulfills your
needs.


> >- 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?

These accesses are developer accesses, so read-write.  Read-only
access is usually provided by other means (e.g. anonymous
smartserver w/o SSH).


> >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 I mentioned, if you think people can live without moving
repositories around, then I think that's best.


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

So basically users can't own their home directory (or maybe with
tricks like chmod +t or chattr +i).

That's possible, but if there's a clear way to tell bzr _not_ to run
user plugins, I think that would be safer.


> >- 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?

These are weird: they made cron to repeatedly stall: after a while
there were lots of idle CRON processes which actually made the system
load rise quite a lot.  This disappeared after I reimplemented them
with the other cron.daily script.  Someday I may try and track down
what went wrong by debugging cron, but this is hard to reproduce;
meanwhile I keep them for reference.

Configuration files are not under a VCS, but a good deal of
information can be found in the bzr repository for project
'administration'.

-- 
Sylvain

signature.asc
Description: Digital signature