info-cvs
[Top][All Lists]
Advanced

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

Re: File permissions


From: yap_noel
Subject: Re: File permissions
Date: Wed, 26 Sep 2001 10:24:50 -0400

>The problem is that, among a lot of "public" files (mode 644), there is
some
>few secret files (mode 600).  "cvs add" will silently ignore any file
>permissions and make the ,v-file world readable (mode 444).
>
>I can think of four solutions to the problem:
>
>1. Keep files that need to be available to the public and files that
should
>be kept secret in separate repositories, and restrict read/execute
>permissions to the "secret" $CVSROOT.  Works well for my case, anyway -
but
>certainly not recommended if there are both public and secret files in the
>same directory.

It's not a good idea to keep public and private files in the same directory
anyway since the directory permissions play a major role in this.  For
example, if write permissions were set for the directory, any of the
private files can be removed.

>2. Keep the secret files away from the CVS repository, they don't belong
>there anyway.

It depends.

>3. Add and commit an empty file with the same filename as the secret file,
>and set the right permissions at the ,v-file before committing the real
>secret file.  I can certainly do that, but I don't expect just any cvs
user
>to do the same.

Again, it's the directory permissions that's important.

>4. Hack cvs, so that it automaticly creates new ,v-files respecting the
>restricted mode of the original file if some command line option is given.
>Eventually let cvs warn if it makes a repository file that is more
readable
>than the work file.

You've done more work and you still have the directory permissions to
contend with.

>It is the last point I really want comments on - is it a smart thing to
do,
>or not?

If you really want to keep these files private, keep them in a separate
repository.  At the very least, keep them in a separate directory and
manage all the permissions extremely carefully.  I think it's much easier
and safer to keep them in a separate repository since the permissions are
easier to manage.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.




reply via email to

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