[Ffmpeg-devel] Re: [MPlayer-dev-eng] mphq2 - admins wanted

[Rich Felker]

On Mon, Sep 05, 2005 at 07:25:31PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Sep 05, 2005 at 12:46:31PM -0400, Rich Felker wrote:
> > On Mon, Sep 05, 2005 at 12:20:39PM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Mon, Sep 05, 2005 at 05:19:02AM -0400, Rich Felker wrote:
> > > > On Mon, Sep 05, 2005 at 09:23:16AM +0200, Attila Kinali wrote:
> > > [...]
> > > 
> > > > 
> > > > > Anyways, any concidered solution has to fullfill 3 criteria:
> > > > > * Secure enough so any break in is unlikely
> > > > 
> > > > IMO this is not sufficient. The minimal condition is: secure enough
> > > > that compromise of a non-root account cannot result in changes to cvs
> > > > repository or content served by the webserver without such changes
> > > > being immediately visible to the entire devel team,
> > > 
> > > iam curious how you want to achive this?
> > > cvs -o, and the fact that the rcs files must be writeable by cvs which
> > > runs with the permissions of the user might make this tricky
> > 
> > It was discussed on irc. The idea is to have the actual cvs repository
> > in a secondary virtualized machine, with no user accounts. User cvs
> > commands sent to the 'user host' would redirect via pserver or ssh to
> > this virtualized machine, with just one actual account restricted to
> > running the trusted cvs binary and nothing else (there would be no
> > other accessible binaries on that host and no writable+executable
> > filesystem).
> 
> and how would file renaming, removing lockfiles and such be handled?

The lockfiles issue needs to be dealt with in a sane way. Can we fix
cvs to get around this brain damage? IMO no lock files should be used
for reading. In some cases this should be trivial to support; in
others, the entire file should be copied before read operations, and
if the source file changed during the copy operation, it should be
copied again, etc. etc. etc. until it stops changing. :) For CVS write
locks we could have a monitor program that removes the lock file is
the process that created it no longer exists.

> how will cvslog messages be generated if theres nothing except cvs on
> the server?

OK, maybe we need another binary; alternatively it could be generated
by the external repository monitor..

> what about secholes in cvs itself, there where some in the past IIRC

AFAIK it was just in pserver, but I may be mistaken.

> they could be exploited to change the repository without generating any
> cvslog messages

It would be nice to have a separate monitoring process that watches
all changes to cvs tree and reports any inconsistencies with cvslog
messages to the cvslog list.

> and cvs -o doesnt generate cvslog messages (sadly ...)

Let's just forbid it.. :)

> and last CVSROOT must be executeable and writeable for normal cvs

WTF? CVS sounds more and more broken by the minute..

> anyway i agree with attila that there are 3 criteria, (one being not being
> overly inconvenient and the other being manageable by the admin team)
> i do have some doubt that your proposal fullflills these but if it does
> iam certainly happy about the added security

Well let's see if we can make it satisfy them..

Rich