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

Michael Niedermayer michaelni
Mon Sep 5 19:25:31 CEST 2005


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?
how will cvslog messages be generated if theres nothing except cvs on
the server?
what about secholes in cvs itself, there where some in the past IIRC
they could be exploited to change the repository without generating any
cvslog messages
and cvs -o doesnt generate cvslog messages (sadly ...)
and last CVSROOT must be executeable and writeable for normal cvs

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

[...] 

-- 
Michael





More information about the ffmpeg-devel mailing list