-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Derek Price wrote:
Derek Price wrote:
I see your point. What about `cvs server'? I
can see both setups being useful... an admin
who allowed users access to the CVS repository
would probably prefer not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
For pserver, the administrator has full control over
the command line.
For server, if the administrator is using a
restricted shell for users, they may or may not be
able to restrict command-line arguments (it
depends on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
For pserver, the administrator has full control over
the command line.
For server, if the administrator is using a
restricted shell for users, they may or may not be
able to
Patch actually attached this time.
Cheers,
Derek
Derek Price wrote:
I've implemented this as an option to server pserver. Installing as a
global option would have create problems in multiroot mode anyhow.
Preliminary patch against 1.11.x attached. The final version will go
into feature -
Derek Price wrote:
Derek Price wrote:
I see your point. What about `cvs server'? I can see both setups being
useful... an admin who allowed users access to the CVS repository would
probably prefer not to allow the config file to be specified whereas an
admin who restriced the command that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
Note that HistoryFile has an argument that would basically be run
through strftime, to enable log rotation. Also see the HistorySearch,
which would be used as a file glob to locate history files to be read
for executions of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Note that HistoryFile has an argument that would basically be run
through strftime, to enable log rotation. Also see the HistorySearch,
which would be used as a file glob to locate
Derek Price wrote:
HistoryFile=$CVSROOT/CVSROOT/logs/history/%Y%m%d
So, if the history file path were configurable and run through
strftime(), I can either (1) cache the history file name the first time
it is determined and gaurantee that all the operations from the same
server execution
write access to other CVSROOT files, history, and val-tags.
I don't think deadlock will be an issue - despite the fact that any
given process writing to the history file or val-tags might hold any
number of other locks, the history or val-tags lock will always be
last in the chain and only held
of other locks, the history or val-tags lock will always be
last in the chain and only held for the duration of the write of a
single line to the file. Does anyone see any problems with that design?
Since file corruption is the current consequence of not having these
locks, I thought this would
for this
(#cvs.history.lock and #cvs.val-tags.lock or somesuch) to allow
concurrent write access to other CVSROOT files, history, and val-tags.
I don't think deadlock will be an issue - despite the fact that any
given process writing to the history file or val-tags might hold any
number of other locks, the history
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Derek Price [EMAIL PROTECTED] writes:
I won't. My apologies for cutting and pasting the list above out of
context from an email I received.
Good, sorry for sounding alarmist. :-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
An associated change I was putting off talking about was adding a
global `-c config_file' option to cause CVS to look elsewhere for
its configuration file.
I worry about the security implications of this one. I don't
Derek Price wrote:
I see your point. What about `cvs server'? I can see both setups being
useful... an admin who allowed users access to the CVS repository would
probably prefer not to allow the config file to be specified whereas an
admin who restriced the command that SSH users could run
14 matches
Mail list logo
