[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -R option fails with pserver

From: Arthur de Jong
Subject: Re: -R option fails with pserver
Date: Sat, 21 Aug 2004 23:55:34 +0200 (CEST)

Hash: SHA1

> The -R option is intended for read-only media such as a CD-R, DVD, or
> read-only network filesystem mount point.
> It is not intended to subvert the permissions model of a remote cvs
> repository maintainer.

I know what the intent is of the -R option but some people pointed me to
the -R option as a way to disable lock files. If you have a repository
that is mostly served as a anonymous read-only pserver and the repository
is not written to a lot (or at all, because the repository is synchronized
remotely) disabeling lock files speeds things up considerably.

> Both of your patches open a :pserver: server maintainer to the
> possibility of users being able to checkout files from the repository
> that they may not otherwise be able to see due to how permissions might
> be maintained in a LockDir directory.

I think a better way to prevent a user from reading files in a repository
is to remove read permission from the file or directory instead of
removing the write permission to the directory. Preventing creation of
lock files should only have consequences for the consistency of the

> Granted that security is not all that tight within cvs, still throwing
> them out altogether is a bad idea.

I have supplied the -R option to the pserver process, not on the client
end so this should have no consequences to the permissions model since the
administrator supplied it and not the user (you cannot enable -R on the
client side for pserver access).

> Actually, mangling the protocol messages is a fine idea if it will help
> stop the use of -R on a remote server....

Well all the other data is sent also so it just takes a patched client to
ignore the warning.

> Sigh. However, it is apparently not really sufficient. If anyone has any
> patches to just disable -R mode when cvs is acting as a server, please
> send them along.

That shouldn't be too hard. Just do an exit() at the place the warning is
currently when pserver was used as a command.

> Also, if any one has patches that allows the repository maintainer to
> relax the creation of locks and instead only enforces permission checks
> to ensure that the user would have been able to create the appropriate
> read lock for the given directory without creating it (this assumes
> there is some compelling case for allowing the moral equivalent of a -R
> switch for read checkouts which I do not think has been proven), such
> patches would be considered for adoption.

I will look into this but I can't promise anything. For me, disabeling the
whole lock stuff would be sufficient.

btw, I'm the maintainer for the cvsd package [1] and one of my users
pointed me to the -R switch.

[1] http://tiefighter.et.tudelft.nl/~arthur/cvsd/

- -- arthur - address@hidden - http://people.debian.org/~adejong --
Version: GnuPG v1.2.4 (GNU/Linux)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]