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

[Sylvain Beucler]

Hi,

On Wed, Mar 17, 2010 at 10:39:51AM +1100, Robert Collins wrote:
> On Wed, 2010-03-17 at 00:13 +0100, Sylvain Beucler 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?
> > > > 
> > > > - I don't understand the roal of a 'bzrusers' group.
> > > 
> > > Neither do I, I think its orthogonal to the bzr+ssh discussion.
> > 
> > Well please clarify.
> 
> unix groups can be used to provide acls on repositories, so its to do
> with access control, not with whether sftp or bzr+ssh is used as the
> protocol.

There is a unix group per Savannah project.


> > ess levels I described?
> > > 
> > > We need to ensure that jrandom cannot write to ~jrandom/.bazaar/plugins.
> > > There is nothing grey about it: If they can write to that directory they
> > > can install plugins. If they cannot write there, then they cannot
> > > install plugins.
> > 
> > I don't know what "plugins" can or can't do.  Can the user run
> > arbitrary commands through bzr+ssh if he has access to that directory?
> 
> plugins are arbitrary python code. They are loaded from two places: the
> system python package 'bzrlib.plugins' and from the users home dir in
> '~/.bazaar/plugins'. A plugin could do anything:
>  - add a new smart server verb
>  - attempt a local code exploit
>  - write to any file the user can write to
> 
> The path that plugins are loaded from is controlled by an environment
> variable, so its important that the commandline of the bzr process on
> the server is strictly controlled - injecting an arbitrary environment
> variable would allow loading a plugin from a non-default location.
[...] 
> I'll need to check, but manually setting the plugins path may be enough;
> it depends on whether we auto-add the homedir location or not.

Yes, if you can configure smartserver not to run user hooks, and make
that a supported use case, that's probably best.


> > > We should make the directory, chown it to root:root and
> > > set it to 0755
> > 
> > Users can bypass this with 'mv'.
> > We would need to also 'chattr +i' but this technique is inconvenient.
> 
> The wouldn't be able to issue a mv with bzr as the directory is outside
> the writable-path we're setting. I agree that if you gave them shell or
> SFTP access they could do that. We are proposing to remove SFTP and not
> give them shell access.
> 
> > > > - 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?
> > > 
> > > There are two major alternatives:
> > >  - an inotify based system that is very similar to the cron job approach
> > >  - bzr-email, which can run server side (but we'll want to give it an
> > > audit to make sure users won't be able to inject a command to run
> > > remotely). I propose to do this during Libre Planet if bzr-email is your
> > > preferred approach. bzr-email would run on push, so have no server load
> > > except when a user has actually pushed something to a branch.
> > 
> > (I'm not at Libre Planet)
> > 
> > I don't have a preferred approach, you tell me how these things scale.
> > For example inotify will probably hit a #descriptors limit, and
> > introduce startup delays when there are many files to minitor which
> > means it may miss changes.
> > 
> > bzr-email may be interesting depending on how plugins are generally
> > run.  However if you keep SFTP access too, this might not be the safer
> > approach.
> 
> I don't see any need to keep SFTP access.
[...]
> > > > >   7. (paranoia) Make sure ~jrandom/.bazaar/plugins does not exist or 
> > > > > is
> > > > >      not writeable by jrandom.  
> > > > >   
> > > > >      NOTE: We may someday put real plugins in there, or make it a
> > > > >      symlink to a shared plugin directory controlled by the sysadmins.
> > > > >      But in any case jrandom should not be able to configure it.
> > > 
> > > Again, while bzr won't be letting them make/delete/rename files outside
> > > of /srv/bzr, a symlink into that directory + appending to it may well
> > > let one write a new file. Its not paranoia to enforce the things one
> > > needs to meet the security policy.
> > 
> > You're talking about combined SFTP&bzr+ssh access (unless I'm
> > mistaken), so let's assume users have write access to their homedir.
> 
> SFTP access is very slow, there is no point having it when bzr+ssh is
> available. If it makes it easier to do bzr+ssh in a way that you are
> happy with, then we should remove SFTP. And it seems like it does to me
> so far.

You can ditch SFTP; though I had the feeling it would be necessary to
manage repositories: declare a new one, switch from a layout to
another, etc.

-- 
Sylvain

signature.asc
Description: Digital signature