Re: Meeting agenda bot, website, git, ssh

Hi,

we now have a git service up and running, in which we can put the data
for our new website and also the to-be-written Meeting agenda bot.

A webview is behind http://git.spi-inc.org/cgi-bin/gitweb.cgi and that
also shows you the git checkout urls for the anonymous clone, basically
the usual simple git://git.spi-inc.org/$project.git

Those that need write access (Hello Ian, MJ, Jimmy) should send me a ssh
key they want to use for it. Clone from git(at)git(dot)spi-inc(dot)org:$project.git

--
bye, Joerg
Some NM:
main contains software that compiles with DFSG.
[hehehe, nice typo]
Of course, eye mean "complies", knot "compiles". Sum typos cant bee
caught bye spelling checkers.

Joerg Jaspert writes ("Meeting agenda bot, website, git, ssh"):
> we now have a git service up and running, in which we can put the data
> for our new website and also the to-be-written Meeting agenda bot.
>
> A webview is behind http://git.spi-inc.org/cgi-bin/gitweb.cgi and that
> also shows you the git checkout urls for the anonymous clone, basically
> the usual simple git://git.spi-inc.org/$project.git

Great.

> Those that need write access (Hello Ian, MJ, Jimmy) should send me a ssh
> key they want to use for it. Clone from git(at)git(dot)spi-inc(dot)org:$project.git

Willdo.

Is there one single access control setup for the whole thing, or are
there several ? It would be nice to be able to let people edit the
website without giving them the power to run code on the server, for
example.

Ian.

>> Those that need write access (Hello Ian, MJ, Jimmy) should send me a ssh
>> key they want to use for it. Clone from git(at)git(dot)spi-inc(dot)org:$project.git
> Willdo.

> Is there one single access control setup for the whole thing, or are
> there several ? It would be nice to be able to let people edit the
> website without giving them the power to run code on the server, for
> example.

Noone gets access to the server directly. :)

(Well, in case someone needs access to a server, we can certainly
arrange things. But thats completly seperate from git access)

--
bye, Joerg
Von einem Besucher auf dem LT:

Die 3 Microsoft-Leute auf Ihrem Stand müssen sich vorkommen wie 3
Mönche im Puff.

Previously Joerg Jaspert wrote:
> >> Those that need write access (Hello Ian, MJ, Jimmy) should send me a ssh
> >> key they want to use for it. Clone from git(at)git(dot)spi-inc(dot)org:$project.git
> > Willdo.
>
> > Is there one single access control setup for the whole thing, or are
> > there several ? It would be nice to be able to let people edit the
> > website without giving them the power to run code on the server, for
> > example.
>
> Noone gets access to the server directly. :)

Did you install the gitweb security fix? :)

Wichert.

--
Wichert Akkerman <wichert(at)wiggy(dot)net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

Joerg Jaspert writes ("Re: Meeting agenda bot, website, git, ssh"):
> [Ian Jackson:]
> > Is there one single access control setup for the whole thing, or are
> > there several ? It would be nice to be able to let people edit the
> > website without giving them the power to run code on the server, for
> > example.
>
> Noone gets access to the server directly. :)
>
> (Well, in case someone needs access to a server, we can certainly
> arrange things. But thats completly seperate from git access)

If the code for something running on the server is kept in git then
effectively everyone who can write to the git can run code on the
server, because even if pushing to the running copy is manual no-one
will review every diff.

Ian.

>> > Is there one single access control setup for the whole thing, or are
>> > there several ? It would be nice to be able to let people edit the
>> > website without giving them the power to run code on the server, for
>> > example.
>> Noone gets access to the server directly. :)
>> (Well, in case someone needs access to a server, we can certainly
>> arrange things. But thats completly seperate from git access)
> If the code for something running on the server is kept in git then
> effectively everyone who can write to the git can run code on the
> server, because even if pushing to the running copy is manual no-one
> will review every diff.

Are we up to splitting hairs now? :)
So, for that:

Noone except us admins has shell access to the box the git repo is on.
Yes, of course, if you can commit stuff you can commit bad things too.
Somehow thats (technically) not avoidable. Unless you want one of us
admins play gatekeeper, and *I* sure not want to add such a
restriction.

--
bye, Joerg
[Kaffeemaschinen und Babies]
Funktioniert aber so ähnlich: Du füllst oben was rein und unten kommt's braun raus...
-- Martin Würtele

Joerg Jaspert writes ("Re: Meeting agenda bot, website, git, ssh"):
> [Ian:]
> > If the code for something running on the server is kept in git then
> > effectively everyone who can write to the git can run code on the
> > server, because even if pushing to the running copy is manual no-one
> > will review every diff.
>
> Are we up to splitting hairs now? :)

This was the motivation for my original question, so not
hair-splitting at all.

> Yes, of course, if you can commit stuff you can commit bad things too.
> Somehow thats (technically) not avoidable. Unless you want one of us
> admins play gatekeeper, and *I* sure not want to add such a
> restriction.

One obvious approach is to have differently-access-controlled git
repositories only some of which are able to take over the machine.

For example, people who need to edit web pages do not need to be able
to run code on the server. I assume (perhaps over-optimistically)
that whatever CMS(s) we are using do not permit the author of the page
data to execute code on the server.

Ian.

Previously Ian Jackson wrote:
> For example, people who need to edit web pages do not need to be able
> to run code on the server. I assume (perhaps over-optimistically)
> that whatever CMS(s) we are using do not permit the author of the page
> data to execute code on the server.
>

THe current CMS (Plone) most certainly does not allow that. Normal users
are not allowed to create any python code. Managers are allowed to
create python scripts via a web interface, but they are executed in a
restricted environment which does not allow any filesystem access, nor
anything else that might be a security risk.

Wichert.

--
Wichert Akkerman <wichert(at)wiggy(dot)net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.