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
