There is an upside to the current implementation design:
there are no r/o actions as far as the local filesystem is concerned:
the libs create transactions (requiring write access) for anything they
query from the database.
bye,
Erik.
> I was thinking of a function along the lines of this. The identifiers
> are made to explain the idea.
>
> {none,r/o,rw} <= AccessToDBDirectory (user-handle, repository-path)
>
> The routine would cull the user's identity and match it against the
> directory/file permissions in the repository. The easiest check would
> be for all files and directories. The downside of that approach is
> that any file, even one not associated with the DB, that is r/o would
> block all write access.
>
> I believe it is reasonable to determine an optimal set of files and
> directories that must have r/w access for the user to be able to write
> the database.
>
>
> On Thu, Sep 04, 2003 at 08:35:34PM +0200, e.huelsmann@gmx.net wrote:
> > I actually tried starting this, but I don't know where I should stick
> the
> > code...
> >
> > I figured that a good place to start would be to look where the database
> > context is created. Only: which files to check the permissions of?
> >
> > bye,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 4 20:54:26 2003