Sylvain Beucler <[email protected]> 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
