Re: Problem with file permissions after checkout/update

[Dave Bartmess]

Thanks for the suggestion. I'm using the cygwin cvs executable. But that
wasn't the problem.

The problem was that the user logged in for checkouts and updates during
the build was a generic user created only on the cvs server. The user
didn't exist on my local machine, since it was rebuilt when I came
onboard with this company.

So I had to 1) add the user as a local user on my machine, and 2) add
the user's passwd (from the local userid) to the cygwin etc/passwd file.

I'm currently looking at talking the boss into re-building the build
machine as a unix box, since the ant scripts are written so that only a
unix environment will build everything correctly (and yes, I'm working
on re-vamping this ant script set, cause it's a mess! ) 

Gotta love it when you inherit someone else's problems!

Just so everyone knows how to fix it in the future! 

On Wed, 2005-03-16 at 10:00 -0500, Todd Denniston wrote:
> Dave Bartmess wrote:
> > 
> > I'm getting files from checkout and update commands that have no file
> > permissions at all... The directories show the directory bit set, but
> > files have NO bits set for permissions.
> > 
> > What could cause this? We're using CVS 1.11.19, on a window platform,
> > and using cygwin for the command line.
> > 
> > This is holding up a build, please help!
> > 
> Reaching for straws... did you use the cygwin cvs client or one of the
> windows based cvs to do the checkout?  Reason for query, not sure what perms
> cygwin would apply to files it did not put in the filesystem.
-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


signature.asc
Description: This is a digitally signed message part
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Problem with file permissions after checkout/update

[Todd Denniston]

Dave Bartmess wrote:
> 
> I'm getting files from checkout and update commands that have no file
> permissions at all... The directories show the directory bit set, but
> files have NO bits set for permissions.
> 
> What could cause this? We're using CVS 1.11.19, on a window platform,
> and using cygwin for the command line.
> 
> This is holding up a build, please help!
> 
Reaching for straws... did you use the cygwin cvs client or one of the
windows based cvs to do the checkout?  Reason for query, not sure what perms
cygwin would apply to files it did not put in the filesystem.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Problem with file permissions after checkout/update

[Dave Bartmess]

I'm getting files from checkout and update commands that have no file
permissions at all... The directories show the directory bit set, but
files have NO bits set for permissions.

What could cause this? We're using CVS 1.11.19, on a window platform,
and using cygwin for the command line.

This is holding up a build, please help!

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


signature.asc
Description: This is a digitally signed message part
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Question on repository file permissions - part 2

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fouts Christopher (6452) <[EMAIL PROTECTED]> writes:

> I have a "sample" project in /cvsroot
> 
> I have a "cvsadmin" user in group "cvs" to manage the sample project.
> cvsadmin is also in group "users". cvsadmin initially created 
> /cvsroot/sample/dir1/file1, and changed group ownership to "users".
> 
> I have a "user1" in group "users" who wants to read from and commit
> to the repository.
> 
> How do I set up my rwx permissions so ALL members of group "users"
> can checkout/checkin from/to the repository, but ONLY cvsadmin can
> "directly" access the repository, that is, through a regular unix
> session and not via cvs.
> 
> If I do chmod g+rwxs sample, anyone in group "users" can directly
> access the repository (i.e., delete files). If I do a g-w, "users" 
> can only checkout, but not checkin.
> 
> -chris

There is a thread on this from February 2004
  http://mail.gnu.org/archive/html/info-cvs/2004-02/msg00359.html
  http://mail.gnu.org/archive/html/info-cvs/2004-02/msg00360.html
  http://mail.gnu.org/archive/html/info-cvs/2004-03/msg0.html

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAdaom3x41pRYZE/gRAiTLAJ9zrWWen+fncYeEcdf++ewm1BOBrwCgsg3d
5Uoj9RXfOBO8wZFLfALZBXs=
=OSA+
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Question on repository file permissions - part 2

[Fouts Christopher (6452)]

I have a "sample" project in /cvsroot

I have a "cvsadmin" user in group "cvs" to manage the sample project.
cvsadmin is also in group "users". cvsadmin initially created 
/cvsroot/sample/dir1/file1, and changed group ownership to "users".

I have a "user1" in group "users" who wants to read from and commit
to the repository.

How do I set up my rwx permissions so ALL members of group "users"
can checkout/checkin from/to the repository, but ONLY cvsadmin can
"directly" access the repository, that is, through a regular unix
session and not via cvs.

If I do chmod g+rwxs sample, anyone in group "users" can directly
access the repository (i.e., delete files). If I do a g-w, "users" 
can only checkout, but not checkin.

-chris







___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Question on repository file permissions

[Fouts Christopher (6452)]

Thanks to all!

-chris

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 08, 2004 12:43 PM
To: Fouts Christopher (6452)
Cc: [EMAIL PROTECTED]
Subject: Re: Question on repository file permissions 


References:
<[EMAIL PROTECTED]>
From: "Mark D. Baushke" <[EMAIL PROTECTED]>
X-Mailer: MH-E 7.4.3+cvs; nmh 1.0.4; GNU Emacs 21.1.1
X-Face:
#8D_6URD2G%vC.hzU,[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Apr 2004 09:42:51 -0700
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]

=2DBEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fouts Christopher (6452) <[EMAIL PROTECTED]> writes:

> I have a "sample" project with r-s permissions for g and o.
> I have dir1/file1 directory/file in the project, which user  cvsadmin 
>in the cvs group, created. so now file1 has
> r--r--r-- permissions.=20
>=20
> I have a separate lock direcotry, called /cvsroot/lockDir  with 
>rwxrwsrwx permissions. =20
> Now user1 in group user checks out sample and modifies
> file1. When user1 checks in file1, it gets
> "Could not open file /cvsroot/sample/dir1/file1, permission denied."
>=20
> I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea
> behind the LockDir was for me (cvs admin) NOT to have to do this?

The idea behind LockDir is to allow folks to do read-only checkouts of files
that they may not normally be allowed to commit as well as to allow for
performance improvements of a very fast in-memory filesystem for the
LockDir.

There are multiple reasons that a LockDir might be desirable including that
this may be a read-only mirror of the main cvs repository that is being
updated via CVSup or some other similar mechanism or that the filesystem is
very slow for writes and an in-memory filesystem is available to deal with
cvs locks.

If you want a given user to be able to commit, you still need for the
directories to have appropriate permissions as the new ,foo, file must still
be created within the repository and then renamed as foo,v for each commit
or tag operation.

Reread http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html

-- Mark
=2DBEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAdYEL3x41pRYZE/gRAjBHAKDDgn/+/8/cUgaZv9dH5wft18MceQCdEeRP
JXvVXAgA0R8tpRp8GXEBcjM=3D
=3DD4SI
=2DEND PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Question on repository file permissions

[Todd Denniston]

"Fouts Christopher (6452)" wrote:
> 
> I have a "sample" project with r-s permissions for g and o.
> I have dir1/file1 directory/file in the project, which user
> cvsadmin in the cvs group, created. so now file1 has
> r--r--r-- permissions.
> 
> I have a separate lock direcotry, called /cvsroot/lockDir
> with rwxrwsrwx permissions.
> 
> Now user1 in group user checks out sample and modifies
> file1. When user1 checks in file1, it gets
> "Could not open file /cvsroot/sample/dir1/file1, permission denied."
> 
> I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea
> behind the LockDir was for me (cvs admin) NOT to have to do this?
> 
> -
> Chris T Fouts
checkin requires the user to write to the repository, for this user1 needs
write privileges to the REPOSITORY.
i.e.
ls -ld /cvsroot/sample/dir1/
#should yield something like:
drwxrwsr-x   # cmuser projgrp512 Jan 26 10:51
/cvsroot/sample/dir1/
#and 
ypcat group >/tmp/look; cat /etc/group /tmp/look| grep user1 
#should yield something like 
projgrp::530:user1,me,restofgroup

LockDir lets you allow more people to read than to write, i.e. you can set it
up so marketing and the PHB can read the repository but never commit.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Question on repository file permissions

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fouts Christopher (6452) <[EMAIL PROTECTED]> writes:

> I have a "sample" project with r-s permissions for g and o.
> I have dir1/file1 directory/file in the project, which user
> cvsadmin in the cvs group, created. so now file1 has
> r--r--r-- permissions. 
> 
> I have a separate lock direcotry, called /cvsroot/lockDir
> with rwxrwsrwx permissions.
> 
> Now user1 in group user checks out sample and modifies
> file1. When user1 checks in file1, it gets
> "Could not open file /cvsroot/sample/dir1/file1, permission denied."
> 
> I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea
> behind the LockDir was for me (cvs admin) NOT to have to do this?

The idea behind LockDir is to allow folks to do read-only checkouts of
files that they may not normally be allowed to commit as well as to
allow for performance improvements of a very fast in-memory filesystem
for the LockDir.

There are multiple reasons that a LockDir might be desirable including
that this may be a read-only mirror of the main cvs repository that is
being updated via CVSup or some other similar mechanism or that the
filesystem is very slow for writes and an in-memory filesystem is
available to deal with cvs locks.

If you want a given user to be able to commit, you still need for the
directories to have appropriate permissions as the new ,foo, file must
still be created within the repository and then renamed as foo,v for
each commit or tag operation.

Reread http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html

-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAdYEL3x41pRYZE/gRAjBHAKDDgn/+/8/cUgaZv9dH5wft18MceQCdEeRP
JXvVXAgA0R8tpRp8GXEBcjM=
=D4SI
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Question on repository file permissions

[Fouts Christopher (6452)]

I have a "sample" project with r-s permissions for g and o.
I have dir1/file1 directory/file in the project, which user
cvsadmin in the cvs group, created. so now file1 has
r--r--r-- permissions. 

I have a separate lock direcotry, called /cvsroot/lockDir
with rwxrwsrwx permissions.

Now user1 in group user checks out sample and modifies
file1. When user1 checks in file1, it gets
"Could not open file /cvsroot/sample/dir1/file1, permission denied."

I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea
behind the LockDir was for me (cvs admin) NOT to have to do this?


-
Chris T Fouts


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions

[Corey Minyard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a patch at http://home.attbi.com/~minyard that might do what you 
want.

- -Corey

Lu Fang wrote:

| Hi, all
| I have installed CVS with cygwin under windows2k operation system. It 
is working properly. Further more,I want to specify the files 
permissions for different group of users. I have read the cvs manualfrom
|
| 
|
| and I have used the command "chmod" to specify a read only access 
rights to the repository for the user named "cvsuser", but I found that 
when I log in as "cvsuser" and tried to access the repository, I can 
check out file and commit file properly, except that there is a warning 
which said that "can not write to history file". What I want is that 
there should be a totally fail if without write permission, but not only 
a warning there.
|
| By the way, can I make the restriction to prevent some user from 
reading some files from the repository? It seems that I can not take 
away the read permission from users by using command "chmod". It seems 
that all the directories and files should be readable at least for all 
the users.
|
| Can anyone give some help? thanks alot!
|
| Lu Fang
|
|
|
|
| _
| Send a fun phone greeting to your friend! 
http://www.msn.com.sg/mobile/fungreetings/
|
|
|
| ___
| Info-cvs mailing list
| [EMAIL PROTECTED]
| http://mail.gnu.org/mailman/listinfo/info-cvs

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+h7n5IXnXXONXERcRAoutAKCzF4fJ6DlsHh4ofH6fzhk8A59VawCcDwOl
+2AM7mmSC6uXxKDd5VL+SD4=
=EsBt
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions

[Dusan Juhas]

Hi Lu,

Please check cvspermissions
http://www.magic-cauldron.com/cm/cvspermissions/cvspermissions.html
if it doesn't meet your requirements.
It's a bunch of shell scripts intented to work on *NIX systems but
hopefully it could work on cygwin.

Regards,
Dusan



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

file permissions

[Lu Fang]

Hi, all
I have installed CVS with cygwin under windows2k operation system. It is 
working properly. Further more,I want to specify the files permissions for 
different group of users. I have read the cvs manualfrom



and I have used the command "chmod" to specify a read only access rights to 
the repository for the user named "cvsuser", but I found that when I log in 
as "cvsuser" and tried to access the repository, I can check out file and 
commit file properly, except that there is a warning which said that "can 
not write to history file". What I want is that there should be a totally 
fail if without write permission, but not only a warning there.

By the way, can I make the restriction to prevent some user from reading 
some files from the repository? It seems that I can not take away the read 
permission from users by using command "chmod". It seems that all the 
directories and files should be readable at least for all the users.

Can anyone give some help? thanks alot!

Lu Fang



_
Send a fun phone greeting to your friend! 
http://www.msn.com.sg/mobile/fungreetings/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions on ',v' files

[Larry Jones]

Jericho writes:
> 
> I have a problem with permissions in directories under in my
> repository.  I noticed today that some files were marked with 'write'
> permission for both the file owner and group.  According to the cvs
> docs, these should only be 'read-only' and not be changed.  

That's correct; write permission is unnecessary and undesirable.

> I'm wondering if this is associated to the error users are seeing, since
> they can't commit to the repository.  They get the following messages
> when they try:
> 
> cvs server: cannot exec (: No such file or directory
> cvs server: Pre-commit check failed
> cvs [server aborted]: correct above errors first!

No.  That error is almost certainly due to a defective commitinfo entry.

-Larry Jones

Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

file permissions on ',v' files

[Jericho]

Hi all,

I have a problem with permissions in directories under in my
repository.  I noticed today that some files were marked with 'write'
permission for both the file owner and group.  According to the cvs
docs, these should only be 'read-only' and not be changed.  

I'm wondering if this is associated to the error users are seeing, since
they can't commit to the repository.  They get the following messages
when they try:

cvs server: cannot exec (: No such file or directory
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!

*CVS exited normally with code 1*

Any ideas?

-- 
Jericho <[EMAIL PROTECTED]>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems with file permissions

[James Hughes]

It sounds like you have the CVSREAD environment variable set, which 
causes files to be set read-only on update or checkout. If this is the 
case, you need to do "cvs edit " to get read-write 
permissions. Or, just unset CVSREAD and you won't have to worry about it.

James

Francis Hwang wrote:
> Sorry, I don't think I was clear enough. What I mean is that when I open the
> file in CVS, it gives me a read-only buffer: Those two % signs on the
> bottom.
> 
> But I'll go ask pcl-cvs. Thanks for the tip!
> 
> Francis
> 
> - Original Message -
> From: "Derek Robert Price" <[EMAIL PROTECTED]>
> To: "Francis Hwang" <[EMAIL PROTECTED]>
> Cc: "Info CVS" <[EMAIL PROTECTED]>
> Sent: Tuesday, August 13, 2002 11:05 AM
> Subject: Re: Problems with file permissions
> 
> 
> 
>>Francis Hwang wrote:
>>
>>
>>>Basically, I open it in Emacs and Emacs won't let me edit it for some
>>>CVS-related reason.
>>>
>>>Francis
>>>
>>>
>>
>>Nothing comes to mind.  It might help if you could tell me the actual
>>error message the machine prints.  You mighc try the pcl-cvs email list
>>too.  pcl-cvs is the Emacs interfact to CVS.  Check <http://cvshome.org>
>>for the exact address of the pcl-cvs email list.
>>
>>
> 
> 
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 

-- 
James Hughes
Esponsive Communications
613-549-3708 ext. 237




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems with file permissions

[Francis Hwang]

Sorry, I don't think I was clear enough. What I mean is that when I open the
file in CVS, it gives me a read-only buffer: Those two % signs on the
bottom.

But I'll go ask pcl-cvs. Thanks for the tip!

Francis

- Original Message -
From: "Derek Robert Price" <[EMAIL PROTECTED]>
To: "Francis Hwang" <[EMAIL PROTECTED]>
Cc: "Info CVS" <[EMAIL PROTECTED]>
Sent: Tuesday, August 13, 2002 11:05 AM
Subject: Re: Problems with file permissions


> Francis Hwang wrote:
>
> >Basically, I open it in Emacs and Emacs won't let me edit it for some
> >CVS-related reason.
> >
> >Francis
> >
> >
>
> Nothing comes to mind.  It might help if you could tell me the actual
> error message the machine prints.  You mighc try the pcl-cvs email list
> too.  pcl-cvs is the Emacs interfact to CVS.  Check <http://cvshome.org>
> for the exact address of the pcl-cvs email list.
>
>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems with file permissions

[Derek Robert Price]

Francis Hwang wrote:

>Basically, I open it in Emacs and Emacs won't let me edit it for some
>CVS-related reason.
>
>Francis
>  
>

Nothing comes to mind.  It might help if you could tell me the actual 
error message the machine prints.  You mighc try the pcl-cvs email list 
too.  pcl-cvs is the Emacs interfact to CVS.  Check  
for the exact address of the pcl-cvs email list.

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
-- 
99. Daddy, why doesn't this magnet pick up this floppy disk? 





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems with file permissions

[Francis Hwang]

Basically, I open it in Emacs and Emacs won't let me edit it for some
CVS-related reason.

Francis

- Original Message -
From: "Derek Robert Price" <[EMAIL PROTECTED]>
To: "Francis Hwang" <[EMAIL PROTECTED]>
Cc: "Info CVS" <[EMAIL PROTECTED]>
Sent: Tuesday, August 13, 2002 8:33 AM
Subject: Re: Problems with file permissions


> Francis Hwang wrote:
>
> >I'm trying to edit a file in my working copy, but emacs isn't letting me.
> >The file permissions on the working copy should be okay, and in the
> >repository I have write access to the directory that it's in, so I'm not
> >sure what's the problem. I do a cvs diff and there's no changes (so it's
not
> >waiting for a commit). I can get around it by deleting the file and then
> >doing a cvs update, but obviously that's not ideal ...
> >
> >I'm sure this is a newbie mistake, but I'd appreciate some help.
> >
> >Francis
> >
> >
>
> What error message are you seeing?
>
> Derek
>
> --
> *8^)
>
> Email: [EMAIL PROTECTED]
>
> Get CVS support at http://ximbiot.com
> --
> The Pledge of Allegiance does not end with "Hail Satan".
> The Pledge of Allegiance does not end with "Hail Satan".
> The Pledge of Allegiance does not end with "Hail Satan"...
>
>   - Bart Simpson on chalkboard, _The Simpsons_
>
>
>
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems with file permissions

[Derek Robert Price]

Francis Hwang wrote:

>I'm trying to edit a file in my working copy, but emacs isn't letting me.
>The file permissions on the working copy should be okay, and in the
>repository I have write access to the directory that it's in, so I'm not
>sure what's the problem. I do a cvs diff and there's no changes (so it's not
>waiting for a commit). I can get around it by deleting the file and then
>doing a cvs update, but obviously that's not ideal ...
>
>I'm sure this is a newbie mistake, but I'd appreciate some help.
>
>Francis
>  
>

What error message are you seeing?

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
-- 
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan"...

  - Bart Simpson on chalkboard, _The Simpsons_





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Problems with file permissions

[Francis Hwang]

I'm trying to edit a file in my working copy, but emacs isn't letting me.
The file permissions on the working copy should be okay, and in the
repository I have write access to the directory that it's in, so I'm not
sure what's the problem. I do a cvs diff and there's no changes (so it's not
waiting for a commit). I can get around it by deleting the file and then
doing a cvs update, but obviously that's not ideal ...

I'm sure this is a newbie mistake, but I'd appreciate some help.

Francis



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvsroot & file permissions ???

[Larry Jones]

Michael D. Schleif writes:
> 
> Starting to use it as a mortal user, I'm having problems with
> directory/file permissions and I cannot find my issues in man cvs, info
> cvs nor a cursory search via google.

<http://www.cvshome.org/docs/manual/cvs_2.html#SEC13>

-Larry Jones

Something COULD happen today.  And if anything DOES,
by golly, I'm going to be ready for it! -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvsroot & file permissions ???

[Michael D. Schleif]

OK, I've installed cvs:

# cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)

I created a repository while I was root (I know, bad) and, as root, I do
not have problems - doh!

Starting to use it as a mortal user, I'm having problems with
directory/file permissions and I cannot find my issues in man cvs, info
cvs nor a cursory search via google.

Should I have overlooked a good faq list, please point me to it ;>

What group, mode and owner be for the special files in $CVSROOR/CVSROOT?

I kept seeing "cannot write to history file", until I changed history to
666 ;<  Of course, my user is a member of group staff.

I am also having problems understanding required group, mode and owner
permissions for directories under modules?

What are the preferred methods for dealing with these issues?

# ls -al ./CVSROOT/
total 152
drwxrwsr-x3 root staff4096 Jul 16 11:33 .
-r--r--r--1 root staff 493 Jul 15 21:00 .#checkoutlist
-r--r--r--1 root staff 760 Jul 15 21:00 .#commitinfo
-r--r--r--1 root staff 527 Jul 15 21:00 .#config
-r--r--r--1 root staff 753 Jul 15 21:00 .#cvswrappers
-r--r--r--1 root staff1025 Jul 15 21:00 .#editinfo
-r--r--r--1 root staff1141 Jul 15 21:00 .#loginfo
-r--r--r--1 root staff1151 Jul 15 21:00 .#modules
-r--r--r--1 root staff 564 Jul 15 21:00 .#notify
-r--r--r--1 root staff 649 Jul 15 21:00 .#rcsinfo
-r--r--r--1 root staff 879 Jul 15 21:00 .#taginfo
-r--r--r--1 root staff1026 Jul 15 21:00 .#verifymsg
drwxrwsr-x4 root staff4096 Jul 16 10:06 ..
drwxrwsr-x2 root staff4096 Jul 15 21:00 Emptydir
-r--r--r--1 root staff 493 Jul 16 11:33 checkoutlist
-r--r--r--1 root staff 692 Jul 15 21:00 checkoutlist,v
-r--r--r--1 root staff 760 Jul 16 11:33 commitinfo
-r--r--r--1 root staff 959 Jul 15 21:00 commitinfo,v
-r--r--r--1 root staff 529 Jul 16 11:33 config
-r--r--r--1 root staff 956 Jul 16 11:33 config,v
-r--r--r--1 root staff 753 Jul 16 11:33 cvswrappers
-r--r--r--1 root staff 952 Jul 15 21:00 cvswrappers,v
-r--r--r--1 root staff1025 Jul 16 11:33 editinfo
-r--r--r--1 root staff1224 Jul 15 21:00 editinfo,v
-rw-rw-rw-1 root staff2425 Jul 16 11:49 history
-r--r--r--1 root staff1141 Jul 16 11:33 loginfo
-r--r--r--1 root staff1340 Jul 15 21:00 loginfo,v
-r--r--r--1 root staff1151 Jul 16 11:33 modules
-r--r--r--1 root staff1350 Jul 15 21:00 modules,v
-r--r--r--1 root staff 564 Jul 16 11:33 notify
-r--r--r--1 root staff 763 Jul 15 21:00 notify,v
-r--r--r--1 root staff 649 Jul 16 11:33 rcsinfo
-r--r--r--1 root staff 848 Jul 15 21:00 rcsinfo,v
-r--r--r--1 root staff 879 Jul 16 11:33 taginfo
-r--r--r--1 root staff1078 Jul 15 21:00 taginfo,v
-rw-rw-r--1 root staff  22 Jul 16 10:32 val-tags
-r--r--r--1 root staff1026 Jul 16 11:33 verifymsg
-r--r--r--1 root staff1225 Jul 15 21:00 verifymsg,v

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import and file permissions

[Dustin Cavanaugh]

> > So, is it necessary to chgrp to "cvs" every new project that I add to the
> > repository?
>
> It's not necessary if you set your repository up correctly. My
> repository has the following permissions:
>
>$> ls -ld /var/cvs
>drwxrwsr-x   16 root cvs  4096 Dec 19 15:34 /var/cvs
>
> The g+s bit ensures that files created retain the group 'cvs'.
> ie:
>
>$> ls -l /var/cvs
>drwxrwsr-x4 crafterm cvs  4096 Dec  4 12:57 project1
>drwxrwsr-x4 crafterm cvs  4096 Dec  1 14:43 project2
>drwxrwsr-x4 crafterm cvs  4096 Dec  3 17:51 project3
>
> Anyone in the cvs group should then have sufficient permissions to
> access/modify these files.
>
> Hope that helps.
>
> Cheers,
>
> Marcus

As a follow-up to what Marcus said, the key is setting the setgid bit. But 
I also notice that you appear to be running CVS as root. Better to run cvs 
as an ordinary user and create wrappers for specific functions. I don't 
know of any exploits using cvs but I'm certainly not going to volunteer my 
system as a guinea pig! ;)

Please notice that Marcus has created another user, "crafterm", to be the 
owner of the repository and cvs runs under that id. The group, "cvs" should 
be stand-alone associated with cvs functions and repositories and nothing else.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS import and file permissions

[Marcus Crafter]

Hi Timur,

On Wed, Dec 19, 2001 at 10:10:33AM -0500, Timur Aydin wrote:
> Hi,
> 
> When I import a new project into the CVS repository, both the owner and
> group of all files are set to my username. This causes trouble, because when
> somebody else wants to check out this project, he gets permission denied
> errors. I guess if I manually change the group of all files to "cvs", then
> things work again. But I couldn't find any statement in the documentation
> that says you have to manually chgrp new projects to "cvs". You do that only
> after cvs init...
> 
> So, is it necessary to chgrp to "cvs" every new project that I add to the
> repository?

It's not necessary if you set your repository up correctly. My
repository has the following permissions:

$> ls -ld /var/cvs
drwxrwsr-x   16 root cvs  4096 Dec 19 15:34 /var/cvs

The g+s bit ensures that files created retain the group 'cvs'.
ie:

$> ls -l /var/cvs
drwxrwsr-x4 crafterm cvs  4096 Dec  4 12:57 project1
drwxrwsr-x4 crafterm cvs  4096 Dec  1 14:43 project2
drwxrwsr-x4 crafterm cvs  4096 Dec  3 17:51 project3

Anyone in the cvs group should then have sufficient permissions to
access/modify these files.

Hope that helps.

Cheers,

Marcus
-- 
.
 ,,$,  Marcus Crafter
;$'  ':Computer Systems Engineer
$: :   ManageSoft GmbH
 $   o_)$$$:   82-84 Mainzer Landstrasse
 ;$,_/\ &&:'   60327 Frankfurt Germany
   ' /( &&&
   \_' Email : [EMAIL PROTECTED]
  .Business Hours : +49 69 9757 200
&&&:

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS import and file permissions

[Timur Aydin]

Hi,

When I import a new project into the CVS repository, both the owner and
group of all files are set to my username. This causes trouble, because when
somebody else wants to check out this project, he gets permission denied
errors. I guess if I manually change the group of all files to "cvs", then
things work again. But I couldn't find any statement in the documentation
that says you have to manually chgrp new projects to "cvs". You do that only
after cvs init...

So, is it necessary to chgrp to "cvs" every new project that I add to the
repository?

--
Timur Aydin
"Behold the power of The Penguin"



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: [Win To Unix] Commit does not work due to file permissions

[Rob Helmer]

Hello Andreas,


On the Unix server you will need to set the group ownership of your
CVS repository ( cvsgroup for example ), and use the SetGID bit to
allow members of that group to take ownership of the files in
question.

What flavor of Unix is this ( Solaris, AIX, etc )? We may be
able to provide more specific help if you specify, otherwise
look at your documentation ( usually the chmod manpage is 
appropriate ).

Please note that you should not access your repository over a 
samba share, as the locking mechanism is lazy enough to cause
problems with CVS ( potentially ). CVS's client/server method
via SSH, RSH or even pserver is preferable to direct file
system access ( not to mention more secure ).



HTH,
Rob Helmer
Namodn


On Wed, Nov 21, 2001 at 04:50:49PM -0800, Andreas Jaeger wrote:
> Hello, 
> 
> I've got a CVS repository on a UNIX file server which is accessible from 
> Windows workstations using Windows shares, in this particular case
> "\\grobi\ifgi\projects\fas\CVSREP". I.e., the clients see the CVS as
> part of the "local" file system. 
> 
> We access the repository from WinCVS 1.2 /1.3beta clients either via 
> the GUI, or via command prompt, or via JBuilder (Java Development IDE)
> using the cvs.exe provided with WinCVS. 
> 
> On the Unix file server, permissions are set to r--r--r-- and the 
> committer takes ownership whenever somebody puts (commits) a file into the 
> repository. While this allows anybody to update their local copies, 
> it prevents them (except the owner) to commit a new version. This
> makes CVS pretty much non-concurrent. I'm not very familiar with
> UNIX, so I do not understand why the file permission is made so 
> restrictive, and how UNIX CVS clients would deal with the situation (i.e.
> change the permissions such as to be able to edit the repository). 
> 
> Andreas
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

[Win To Unix] Commit does not work due to file permissions

[Andreas Jaeger]

Hello, 

I've got a CVS repository on a UNIX file server which is accessible from 
Windows workstations using Windows shares, in this particular case
"\\grobi\ifgi\projects\fas\CVSREP". I.e., the clients see the CVS as
part of the "local" file system. 

We access the repository from WinCVS 1.2 /1.3beta clients either via 
the GUI, or via command prompt, or via JBuilder (Java Development IDE)
using the cvs.exe provided with WinCVS. 

On the Unix file server, permissions are set to r--r--r-- and the 
committer takes ownership whenever somebody puts (commits) a file into the 
repository. While this allows anybody to update their local copies, 
it prevents them (except the owner) to commit a new version. This
makes CVS pretty much non-concurrent. I'm not very familiar with
UNIX, so I do not understand why the file permission is made so 
restrictive, and how UNIX CVS clients would deal with the situation (i.e.
change the permissions such as to be able to edit the repository). 

Andreas
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Tuesday, September 25, 2001 at 17:06:43 (-0700), Paul Sander wrote: ]
>> Subject: Re: File permissions
>>
>> There's nothing wrong with adding meta-data.

>Well, it all depends on what the meta data is, and what use is made of
>it by the overall system.

>Where the needs of the versioning tool conflict with the needs of the
>target system, an intermediate process must be used to separate the
>meta-data so that the conflict does not occur.

I think that's what I said in the following paragraphs of that posting:
Store data that describe the data, don't encode the process.

>--- End of forwarded message from [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Thursday, September 27, 2001 at 03:25:16 (+0400), Tobias Brox wrote: ]
> Subject: Re: File permissions
>
> Could be - i.e. use a Makefile to describe how things should look at the
> target system.

Exactly.

> Then some external tool to import a target directory into a Makefile and
> source files might be a considered idea...

I'm not sure a tool like that would be of much use.  If you're going to
be managing these kinds of file attributes (e.g. permissions,
ownerships, links, etc.) then you really do have to know what you're
doing and you really should be able to concretely define the state you
want the target files to be in -- a tool that tried to do this for you
would have to assume you'd already set things up in the desired fashion
in the first place and as such would undoubtably only copy your mistakes.

The other problem with this kind of thing is that a tool really cannot
ever understand the goals of your policy (at least not without
significant external input from you, the expert, which kinda makes the
tool very redundant and useless), and as a result any such tool is
undoubtably going to have to take the "overkill" approach and thus it
will obscure the important information in amongst all the irrelevent
chaff that it must record.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Wednesday, September 26, 2001 at 23:58:07 (+0400), Tobias Brox wrote: ]
> Subject: Re: File permissions
>
> So your local setup would break up if setting "PreservePermission" in the
> CVS config?

I would imagine so.  I've never set it, and it's now deprecated, so I
don't care.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Tobias Brox]

[Greg A. Woods - Wed at 03:47:09PM -0400]
> The only really successful way to attack this problem is to separate the
> versioning process from the process of creating the target files.

Could be - i.e. use a Makefile to describe how things should look at the
target system.

Then some external tool to import a target directory into a Makefile and
source files might be a considered idea...

-- 
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Tuesday, September 25, 2001 at 19:34:29 (-0400), Eric Siegerman wrote: ]
> Subject: Re: File permissions
>
> On Tue, Sep 25, 2001 at 03:47:57PM -0400, Greg A. Woods wrote:
> > 
> > There's no way to handle _any_ file attribute change tracking without
> > extending the RCS file format.  Period.
> 
> And the RCS file format is explicitly extensible.  Read
> rcsfile(5); look for "newphrase".

Eric, read what I said above again  I didn't say RCS wasn't
extensible -- I just said that you can't track attribute changes without
extending the file format.

> But this:
> > Take it up with the RCS maintainers if you want to do something
> > productive about it.
> is horsefeathers.

"extensibility" != doing things in a way that will be of any benefit

Someone interested in extending or changing the structure of RCS-format
files (be it for RCS directly, or something else that uses the same
format, eg. CVS), really does need to learn a *lot* for the experience
of the RCS maintainers (and probably a lot from people who understand
filesystems and such too!).

This goes double for versioning file attributes such as permissions,
ownerships, links, etc.

This whole concept of "tracking attribute changes" is very very very
complex to get right.  There is a fundament, basic, inescapable,
conflict between the needs of the repository for access control and
other such file-attribute controlled mechanisms and the related needs of
the system that the target files are components of.  It CANNOT be
resolved by simply putting attribute tracking in the versioning tool.

The only really successful way to attack this problem is to separate the
versioning process from the process of creating the target files.
I.e. to use a build system that transforms the "source" files into
"target" files (which may be as simple as setting some attributes, or it
may involve detailed and complex steps such as translation of their
contents).

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Tuesday, September 25, 2001 at 17:06:43 (-0700), Paul Sander wrote: ]
> Subject: Re: File permissions
>
> There's nothing wrong with adding meta-data.

Well, it all depends on what the meta data is, and what use is made of
it by the overall system.

Where the needs of the versioning tool conflict with the needs of the
target system, an intermediate process must be used to separate the
meta-data so that the conflict does not occur.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Tobias Brox]

[Greg A. Woods - Wed at 03:52:05PM -0400]
> > Is RCS still beeing developed at all?
> 
> RCS is being maintained ...

Sorry my ignorance - the last entry at the changelog here is from 1995, and
I can't check up anything through the 'net at the moment.

> Well, some of us rely both directly and indirectly on the fact that CVS
> uses RCS for the underlying repository structure.  Any incompatability
> would force us to revert to a compatible version again.

So your local setup would break up if setting "PreservePermission" in the
CVS config?

-- 
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Wednesday, September 26, 2001 at 01:00:36 (+0400), Tobias Brox wrote: ]
> Subject: Re: File permissions
> 
> Is RCS still beeing developed at all?

RCS is being maintained and it is still very very very widely used.

> I see no reason why the frame of the RCS file format should be a definite
> blocker for what features there can be in CVS.  After all, if RCS was
> perfect, there would be no need for CVS?

Well, some of us rely both directly and indirectly on the fact that CVS
uses RCS for the underlying repository structure.  Any incompatability
would force us to revert to a compatible version again.

> Information that won't fit into the ,v-files can be stored elsewere.  It
> adds complexity, and that's undesireable - but it's certainly possible.

almost anything's possible in theory -- but it's the sane, pragmatic,
productive things that we're concerned with here.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[yap_noel]

>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.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>On Tue, Sep 25, 2001 at 03:47:57PM -0400, Greg A. Woods wrote:
>> [ On Tuesday, September 25, 2001 at 21:08:59 (+0400), Tobias Brox wrote: ]
>> > Subject: File permissions

>Kaz Kylheku recently took up my challenge to give *valid* reasons
>not to track file metadata:
>   http://mail.gnu.org/pipermail/info-cvs/2001-September/019853.html
>I'm semi-convinced :-)

There's nothing wrong with adding meta-data.  Just remember that
metadata are data about data; that is, metadata describe data.  In
a version control setting, metadata should not describe process.
We have other mechanisms, such as makefiles, that are perfectly
good at that.

On the other hand, RCS already stores a bunch of metadata:  tags
(both branch and version tags), revision log commentary, per-version
state, text deltas, checkin times, and so on.  All of these describe
the state of a source file at various times, but they do not specify
how to process the source file.  Other things could be added that make
sense:  data type and merge history are obvious examples.

There is a grey area, particularly with regard to multi-part files.
Archive files, Apple's resource forks, and various kinds of documents
that get stored in the filesystem as many files that must tracked as a
unit (e.g. NextStep) come to mind.  Stuff like this can be coded into
a data type handler, which CVS doesn't have at present.  But again, the
metadata describe the data, the type handler implements process.  There
is a difference.

Kaz' exmaples of platform-dependent permissions, make-like rules, and
so on, describe process:  What is done to the file once it's copied out
of the version control system and into the filesystem.

>--- End of forwarded message from [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Larry Jones]

Tobias Brox writes:
> 
> Information that won't fit into the ,v-files can be stored elsewere.  It
> adds complexity, and that's undesireable - but it's certainly possible.

The RCS file format is explicitly extensible (see the rcsfile man page),
so that shouldn't be necessary.

-Larry Jones

It's SUSIE!  It's a GIRL!  Santa would understand! -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Eric Siegerman]

On Tue, Sep 25, 2001 at 03:47:57PM -0400, Greg A. Woods wrote:
> [ On Tuesday, September 25, 2001 at 21:08:59 (+0400), Tobias Brox wrote: ]
> > Subject: File permissions
> >
> > saving, and later restoring simple file permissions and ownership really
> > shouldn't be that hard, and I'd daresay it can be a nice feature,
> > particularly when storing configuration files in cvs.
> 
> There's no way to handle _any_ file attribute change tracking without
> extending the RCS file format.  Period.

And the RCS file format is explicitly extensible.  Read
rcsfile(5); look for "newphrase".

Kaz Kylheku recently took up my challenge to give *valid* reasons
not to track file metadata:
http://mail.gnu.org/pipermail/info-cvs/2001-September/019853.html
I'm semi-convinced :-)

But this:
> Take it up with the RCS maintainers if you want to do something
> productive about it.
is horsefeathers.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
The world has been attacked.  The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short run.
- Jean Chrétien, Prime Minister of Canada

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[Greg A. Woods - Tue at 03:47:57PM -0400]
>> There's no way to handle _any_ file attribute change tracking without
>> extending the RCS file format.  Period.

>When PreservePermission is set, the information is actually written to the
>RCS files.  Is this a gross hack?  Does it break up RCS somehow?

>> Take it up with the RCS maintainers if you want to do something productive
>> about it.

>Is RCS still beeing developed at all?

>I see no reason why the frame of the RCS file format should be a definite
>blocker for what features there can be in CVS.  After all, if RCS was
>perfect, there would be no need for CVS?

>Information that won't fit into the ,v-files can be stored elsewere.  It
>adds complexity, and that's undesireable - but it's certainly possible.

The RCS file format also provides a way to extend the format without
breaking compatibility, both at the file and version levels.  Naming
conventions can provide a measure of protection from collisions in the
event that RCS files are shared between multiple version control systems
that both make extensions.

And since CVS writes the RCS files directly (i.e. without the benefit
of the RCS executables), it should not be difficult to add such extensions.

>--- End of forwarded message from [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Tobias Brox]

[Matt Riechers - Tue at 02:47:48PM -0400]
> On the same thought, you could also create a seperate repository just for admin
> files, readable only by root.

Just what I ment ... though ... I probably didn't express myself clearly
enough:

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.

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

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.

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.

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


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Tobias Brox]

[Greg A. Woods - Tue at 03:47:57PM -0400]
> There's no way to handle _any_ file attribute change tracking without
> extending the RCS file format.  Period.

When PreservePermission is set, the information is actually written to the
RCS files.  Is this a gross hack?  Does it break up RCS somehow?

> Take it up with the RCS maintainers if you want to do something productive
> about it.

Is RCS still beeing developed at all?

I see no reason why the frame of the RCS file format should be a definite
blocker for what features there can be in CVS.  After all, if RCS was
perfect, there would be no need for CVS?

Information that won't fit into the ,v-files can be stored elsewere.  It
adds complexity, and that's undesireable - but it's certainly possible.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Greg A. Woods]

[ On Tuesday, September 25, 2001 at 21:08:59 (+0400), Tobias Brox wrote: ]
> Subject: File permissions
>
> Particularly hardlinks must be a quite difficult thing to deal with, but
> saving, and later restoring simple file permissions and ownership really
> shouldn't be that hard, and I'd daresay it can be a nice feature,
> particularly when storing configuration files in cvs.

There's no way to handle _any_ file attribute change tracking without
extending the RCS file format.  Period.  Take it up with the RCS
maintainers if you want to do something productive about it.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions

[Matt Riechers]

Tobias Brox wrote:
> 
> Another issue about file permissions ... I'd like to keep most of /etc in
> cvs.  Unfortunately, this includes some few secret files.  Checking them in
> leaves the ,v-files world-readable.  I think it could be wise to let cvs
> check for restricted readability of files, and store the ,v-files with the
> same permission and ownership as the original files.  Well.  I guess I could
> solve the problem by just leaving the CVSROOT unreadable for anyone else
> than the system administrator.  Comments?

On the same thought, you could also create a seperate repository just for admin
files, readable only by root.

-Matt

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

File permissions

[Tobias Brox]

[Larry Jones]
> The PreservePermissions code is notoriously buggy and should not be
> used.  Recent versions of CVS omit it by default and the manual no
> longer mentions it at all.

Particularly hardlinks must be a quite difficult thing to deal with, but
saving, and later restoring simple file permissions and ownership really
shouldn't be that hard, and I'd daresay it can be a nice feature,
particularly when storing configuration files in cvs.

As a matter of fact, I have absolutely nothing else to do this week, so I
might eventually take a look into the sources and see if I can do anything.
Will patches eventually be accepted?

Another issue about file permissions ... I'd like to keep most of /etc in
cvs.  Unfortunately, this includes some few secret files.  Checking them in
leaves the ,v-files world-readable.  I think it could be wise to let cvs
check for restricted readability of files, and store the ,v-files with the
same permission and ownership as the original files.  Well.  I guess I could
solve the problem by just leaving the CVSROOT unreadable for anyone else
than the system administrator.  Comments?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: File permissions [make that directory permissions!]

[Tracy Brown]

Actually, my reply was not in reference to my own situation but rather
another mail. I do agree with Greg's sentiments about security and without a
doubt pserver is not secure.

There is some question as to how much security a UNIX account adds in an
internal environment. While an internal employee can spoof my pserver
configuration, users with a shell account can also spoof CVS unless
token-based authentication systems are implemented such as Kerberos, etc.
Perhaps there are configurations using SSH that can accommodate this.

I'm not questioning the security implications of my own configurations. In
my other configuration that is secure, I use Kerberos (GSS-API), tcp
compression, 3des encryption, database driven ACLs, and UNIX group
permissions. Yet, even in this configuration I do not need to hand out UNIX
accounts since users authenticate through my KDC (i.e. grab a TGT) and
access CVS using the gserver protocol. The CVS usage ACL is done within the
KDC - and the module/file level modification ACLs are done through a
combination of database queries and group permissions.

The purpose of my message was only to illustrate that in a relatively
trusted environment, pserver authentication does have some level of
accountability. While this can be spoofed, it may be unreasonable to go to
the depths of a highly secure environment depending on the sensitivity of
that data within the repository. I do not think that while the potential for
spooking is there in pserver, there is no accountability.

Tracy.


-Original Message-
From: Chris Cameron
To: CVS-II Discussion Mailing List; Tracy Brown
Sent: 5/22/01 4:37 PM
Subject: RE: File permissions [make that directory permissions!]

Without contradicting any of Gregs comments on security, which have been
aired in this forum too many times to count, I feel that Greg's last
paragraph is the most relevant.  What is the background to the original
question?  Is this an internal or external project?  What are you trying
to
protect against?  Malicious users or uses who may do potentially
damaging
operations without being aware of it?

***
Chris Cameron   Open Telecommunications Ltd
Product Manager   IN Product Management
[EMAIL PROTECTED]   P.O.Box 10-388
  +64 4 495 8403 (DDI)  The Terrace
fax:  +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Greg A. Woods
Sent: Wednesday, 23 May 2001 10:44 a.m.
To: Tracy Brown
Cc: CVS-II Discussion Mailing List
Subject: RE: File permissions [make that directory permissions!]


[ On Tuesday, May 22, 2001 at 14:19:42 (-0700), Tracy Brown wrote: ]
> Subject: RE: File permissions [make that directory permissions!]
>
> I'm a little confused. For my user base, none have UNIX shell
accounts.
> In the pserver password file:
>   user:password:user_to_run_as
>   i.e.
>   bob:lsfdkuhsdf:pubcvs
>
> The $USER var will return the user (bob) and not the optional
user_to_run_as
>
> (pubcvs) as noted in the above example. Thus, I can hold my users
> accountable to their modifications made in the repository.

Where do you get that idea?  There's only one user accountable for the
repository and that's the user the pserver thing runs as.  Any apparent
accountability offered by pserver is only an illusion that cannot be
verified.

Accountability in Unix *requires* Unix user-ids for each entity that's
to be held accountable.  You cannot eat your cake and have it too.

Note that because CVS is not a security tool and thus does not have any
real security within it, it cannot do secure authentication and secure
authorisation and it cannot prevent one fake user from making it look
like some other fake user did something in the repository.  CVS pserver
has no accountability whatsoever.  You are dreaming if you think
otherwise.  It also has no privacy whatsoever (unless you tunnel it
through SSH, but that's rather pointless since you've got to create Unix
accounts for SSH anyway).  Without privacy the passwords, the code,
etc., all passes over the network in the clear and without any
protection from man-in-the-middle attacks (such as connection hijacking,
connection spoofing, etc.).  Trivial off-the-shelf tools will allow
anyone with access to your network to do any manner of things to a
pserver connection.  With a tiny amount of additional work this might
even include doing things like stuffing trojan code into your repository
during a commit by someone else!

> As an administrator I really don't want to manage 100+ UNIX accounts
just
> because I should trust them... that's

RE: File permissions [make that directory permissions!]

[Chris Cameron]

Without contradicting any of Gregs comments on security, which have been
aired in this forum too many times to count, I feel that Greg's last
paragraph is the most relevant.  What is the background to the original
question?  Is this an internal or external project?  What are you trying to
protect against?  Malicious users or uses who may do potentially damaging
operations without being aware of it?

***
Chris Cameron   Open Telecommunications Ltd
Product Manager   IN Product Management
[EMAIL PROTECTED]   P.O.Box 10-388
  +64 4 495 8403 (DDI)  The Terrace
fax:  +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Greg A. Woods
Sent: Wednesday, 23 May 2001 10:44 a.m.
To: Tracy Brown
Cc: CVS-II Discussion Mailing List
Subject: RE: File permissions [make that directory permissions!]


[ On Tuesday, May 22, 2001 at 14:19:42 (-0700), Tracy Brown wrote: ]
> Subject: RE: File permissions [make that directory permissions!]
>
> I'm a little confused. For my user base, none have UNIX shell accounts.
> In the pserver password file:
>   user:password:user_to_run_as
>   i.e.
>   bob:lsfdkuhsdf:pubcvs
>
> The $USER var will return the user (bob) and not the optional
user_to_run_as
>
> (pubcvs) as noted in the above example. Thus, I can hold my users
> accountable to their modifications made in the repository.

Where do you get that idea?  There's only one user accountable for the
repository and that's the user the pserver thing runs as.  Any apparent
accountability offered by pserver is only an illusion that cannot be
verified.

Accountability in Unix *requires* Unix user-ids for each entity that's
to be held accountable.  You cannot eat your cake and have it too.

Note that because CVS is not a security tool and thus does not have any
real security within it, it cannot do secure authentication and secure
authorisation and it cannot prevent one fake user from making it look
like some other fake user did something in the repository.  CVS pserver
has no accountability whatsoever.  You are dreaming if you think
otherwise.  It also has no privacy whatsoever (unless you tunnel it
through SSH, but that's rather pointless since you've got to create Unix
accounts for SSH anyway).  Without privacy the passwords, the code,
etc., all passes over the network in the clear and without any
protection from man-in-the-middle attacks (such as connection hijacking,
connection spoofing, etc.).  Trivial off-the-shelf tools will allow
anyone with access to your network to do any manner of things to a
pserver connection.  With a tiny amount of additional work this might
even include doing things like stuffing trojan code into your repository
during a commit by someone else!

> As an administrator I really don't want to manage 100+ UNIX accounts just
> because I should trust them... that's a hassle. And we don't need to -
> we can obtain accountability without this silly hassle.

You would rather administer fake accounts in some insecure
application?!?!?!?

Real unix accounts are most definitely *NOT* any kind of "hassle"!
You're fooling yourself and focusing on the wrong issues.  When you go
to get a driver's license it's not just a photocopy of some master --
it's a unique document personalised to the person it is granted to.

Note that you don't have to *support* full shell access to the server,
but you do have to be aware that the possibility is there and that it
cannot be prevented, pserver or not.  (SSH+chroot might be able to
restrict what parts and services on the server are visible and usable by
the user, but otherwise don't change the equation w.r.t. the repository
itself; and I personally would never use them in place of having a
separate server.)

If you're offering access to important files on your system then you
really do want to create real individual Unix accounts for each and
every entity you authorise such access for!  With only fake pserver
accounts you're providing all of the trappings (and hinding behind them)
but none of the substance of real security controls.

You are in fact implicitly trusting pserver users with what ammounts to
shell access as the pserver user -- you just don't have any basis for
that trust because you really cannot hold them accountable and you have
not really authenticated them.  Without using some external auditing
process where the programmers are each individually required to
re-verify the origin and intgrity of each of their changes the code in
that reposit

RE: File permissions [make that directory permissions!]

[Greg A. Woods]

[ On Tuesday, May 22, 2001 at 14:19:42 (-0700), Tracy Brown wrote: ]
> Subject: RE: File permissions [make that directory permissions!]
>
> I'm a little confused. For my user base, none have UNIX shell accounts. 
> In the pserver password file:
>   user:password:user_to_run_as
>   i.e.
>   bob:lsfdkuhsdf:pubcvs
> 
> The $USER var will return the user (bob) and not the optional user_to_run_as
> 
> (pubcvs) as noted in the above example. Thus, I can hold my users
> accountable to their modifications made in the repository.

Where do you get that idea?  There's only one user accountable for the
repository and that's the user the pserver thing runs as.  Any apparent
accountability offered by pserver is only an illusion that cannot be
verified.

Accountability in Unix *requires* Unix user-ids for each entity that's
to be held accountable.  You cannot eat your cake and have it too.

Note that because CVS is not a security tool and thus does not have any
real security within it, it cannot do secure authentication and secure
authorisation and it cannot prevent one fake user from making it look
like some other fake user did something in the repository.  CVS pserver
has no accountability whatsoever.  You are dreaming if you think
otherwise.  It also has no privacy whatsoever (unless you tunnel it
through SSH, but that's rather pointless since you've got to create Unix
accounts for SSH anyway).  Without privacy the passwords, the code,
etc., all passes over the network in the clear and without any
protection from man-in-the-middle attacks (such as connection hijacking,
connection spoofing, etc.).  Trivial off-the-shelf tools will allow
anyone with access to your network to do any manner of things to a
pserver connection.  With a tiny amount of additional work this might
even include doing things like stuffing trojan code into your repository
during a commit by someone else!

> As an administrator I really don't want to manage 100+ UNIX accounts just
> because I should trust them... that's a hassle. And we don't need to - 
> we can obtain accountability without this silly hassle.

You would rather administer fake accounts in some insecure application?!?!?!?

Real unix accounts are most definitely *NOT* any kind of "hassle"!
You're fooling yourself and focusing on the wrong issues.  When you go
to get a driver's license it's not just a photocopy of some master --
it's a unique document personalised to the person it is granted to.

Note that you don't have to *support* full shell access to the server,
but you do have to be aware that the possibility is there and that it
cannot be prevented, pserver or not.  (SSH+chroot might be able to
restrict what parts and services on the server are visible and usable by
the user, but otherwise don't change the equation w.r.t. the repository
itself; and I personally would never use them in place of having a
separate server.)

If you're offering access to important files on your system then you
really do want to create real individual Unix accounts for each and
every entity you authorise such access for!  With only fake pserver
accounts you're providing all of the trappings (and hinding behind them)
but none of the substance of real security controls.

You are in fact implicitly trusting pserver users with what ammounts to
shell access as the pserver user -- you just don't have any basis for
that trust because you really cannot hold them accountable and you have
not really authenticated them.  Without using some external auditing
process where the programmers are each individually required to
re-verify the origin and intgrity of each of their changes the code in
that repository could have been changed by anyone with IP access to the
machine.

If you don't want to add Unix user accounts for each real user then
please don't fool yourself into thinking your repository (or even the
system it resides on) is secure -- treat its status for what it really
is:  an anonymous repository.  You'll probably even be more secure
overall if you don't have any passords on the pserver accounts -- that
way everyone will be forced to be more aware of the situation and will
look out for each other and for intruders.

Note of course that if your machine is physically secure and if you have
an external security policy covering all your users with remedies that
will prevent them from violating that policy without paying the price
then much of what I say above may be irrelevant for your specific
situation.  However if the "rewards" are high enough for an attacker
then the "threats" imposed by an external security policy may not be
enough of a deterrent to stop the attacker, and so without real
accountability and true technical controls in your systems you leave all
the other users open to redirection of suspicion

RE: File permissions [make that directory permissions!]

[Tracy Brown]

<..snip..>
> > (They already have
> > ssh access, at this moment, at a later time I might 
> consider pserver if
> > I want to add people to the project that shouldn't have a shell
> > account...)
> 
> No, don't do that.  There's no protection in CVS to prevent users from
> doing almost arbitrary things (nor should there be -- CVS is not a
> security tool!).  Furthermore there's no accountability in 
> pserver.  Use
> real Unix accounts for what they're designed for!  If you don't trust
> someone with a Unix account then you certainly can't trust them with
> your code.  If the issue is really that they can't be trusted 
> with some
> other thing on the same server then your only real option is 
> to move the
> CVS repo to some other machine where there's no conflict between trust
> requirements.

I'm a little confused. For my user base, none have UNIX shell accounts. 
In the pserver password file:
user:password:user_to_run_as
i.e.
bob:lsfdkuhsdf:pubcvs

The $USER var will return the user (bob) and not the optional user_to_run_as

(pubcvs) as noted in the above example. Thus, I can hold my users
accountable to their modifications made in the repository. This is done
by having one of more accounts such as pubcvs in the example above. Bob
will authenticate with his password and run on the pubcvs account and yet
all Bob's transactions will be his and not pubcvs's.

As an administrator I really don't want to manage 100+ UNIX accounts just
because I should trust them... that's a hassle. And we don't need to - 
we can obtain accountability without this silly hassle.

And if you want to impose permissions, use a set of UNIX groups with a set
of public cvs accounts (i.e. pubcvs1, pubcvs2, pubcvs3, etc.). Oh, and keep
the password for these users to yourself, turn off telnet, turn off ftp, and
all that UNIX administration stuff.

If security is on your mind:
http://www.idealx.org/prj/idx-chrooted-ssh-cvs/index.en.html
[or]
http://www.ornl.gov/~jar/cvs.html


<..snip..> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions [make that directory permissions!]

[Greg A. Woods]

[ On Tuesday, May 22, 2001 at 15:57:34 (+0200), Hugo van der Merwe wrote: ]
> Subject: File permissions (Was: Re: pserver vs. ssh - performance ...)
>
> Having now started using my CVS repository for shared projects instead
> of just personal ones, I have come to wonder about file permissions...
> my cvs repository belongs to the "src" group, so I add users to that
> group if they should have access to the repository.

sounds good so far!

(well, except for the part about "file permissions" -- CVS uses
directory permissions to control access to all the files within that
directory.)

((yes, pedantically a directory is a file :-))

> (They already have
> ssh access, at this moment, at a later time I might consider pserver if
> I want to add people to the project that shouldn't have a shell
> account...)

No, don't do that.  There's no protection in CVS to prevent users from
doing almost arbitrary things (nor should there be -- CVS is not a
security tool!).  Furthermore there's no accountability in pserver.  Use
real Unix accounts for what they're designed for!  If you don't trust
someone with a Unix account then you certainly can't trust them with
your code.  If the issue is really that they can't be trusted with some
other thing on the same server then your only real option is to move the
CVS repo to some other machine where there's no conflict between trust
requirements.

> Now I wonder, as any of those users can modify any file in this
> structure, is "trust" the only way I can stop them from messing with my
> other projects?

If you want to provide separate "rights" to modify different modules for
different groups of users then the simplest scheme is to create a unix
group for each common group of users and then make all the directories
in each module for a group of users be owned and writable only by their
unix group.  You have to take care to maintain this properly, especially
if your filesystem doesn't help do it with you (i.e. new directories
must be checked and perhaps corrected).

> (Must I create a second repository with different "group
> ownership" for this?)

Not necessarily, but you can also do this too.

> Secondly, with any user being able to modify
> CVSROOT, as what user does the commands get executed, e.g. commit mails
> from commitinfo... these run as the user doing the commit I assume? That
> means any user can cause any other user to run an arbitrary command as
> himself... ?

The CVSROOT directory is just another module.  Create a "cvsadmin" group
and make the $CVSROOT/CVSROOT directory writable only by that group.
Only add users to the "cvsadmin" group if you want to allow them to
administer the CVS repository itself.

Indeed anyone with write access to the CVSROOT module can introduce
"trojan horse" programs into the *info files (or the scripts or programs
already configured in the *info files if you also install those scripts
and programs in the CVSROOT module instead of in some secure place where
they really should be).

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions (Was: Re: pserver vs. ssh - performance ...)

[Noel L Yap]

I haven't been following this thread so forgive me if I repeat anything.

Along with standard file system permissioning, you may want to see if your file
system supports ACLs (man setfacl and getfacl for more info).

Also, if you use SSH, you can limit the server to CVS access only (see SSH docs
on how to do this), thereby preventing direct access to the repo.

Noel





Hugo van der Merwe writes:
>
> Now I wonder, as any of those users can modify any file in this
> structure, is "trust" the only way I can stop them from messing with my
> other projects?

The way you have things currently set up, yes.

> (Must I create a second repository with different "group
> ownership" for this?)

You don't have to go that far -- you can set the ownership of different
directories in a single repository so that only users in a particular
group can read and/or write them.

> Secondly, with any user being able to modify
> CVSROOT, as what user does the commands get executed, e.g. commit mails
> from commitinfo... these run as the user doing the commit I assume?

That's correct.

> That
> means any user can cause any other user to run an arbitrary command as
> himself... ?

That's also correct.  But CVSROOT is just a directory like any other
directory -- if you change it to be owned by a different group and only
give that group write privilege, then only memebers of that group will
be able to change the files in it.

-Larry Jones

I keep forgetting that rules are only for little nice people. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs




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.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File permissions (Was: Re: pserver vs. ssh - performance ...)

[Larry Jones]

Hugo van der Merwe writes:
> 
> Now I wonder, as any of those users can modify any file in this
> structure, is "trust" the only way I can stop them from messing with my
> other projects?

The way you have things currently set up, yes.

> (Must I create a second repository with different "group
> ownership" for this?)

You don't have to go that far -- you can set the ownership of different
directories in a single repository so that only users in a particular
group can read and/or write them.

> Secondly, with any user being able to modify
> CVSROOT, as what user does the commands get executed, e.g. commit mails
> from commitinfo... these run as the user doing the commit I assume? 

That's correct.

> That
> means any user can cause any other user to run an arbitrary command as
> himself... ?

That's also correct.  But CVSROOT is just a directory like any other
directory -- if you change it to be owned by a different group and only
give that group write privilege, then only memebers of that group will
be able to change the files in it.

-Larry Jones

I keep forgetting that rules are only for little nice people. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

File permissions (Was: Re: pserver vs. ssh - performance ...)

[Hugo van der Merwe]

On Sat, May 19, 2001 at 03:13:15PM -0400, Larry Jones wrote:

> Performance should be essentially the same in either case.  ssh has a
> privacy/security advantage since the entire communication is strongly
> encrypted; pserver is somewhat easier to set up.


Having now started using my CVS repository for shared projects instead
of just personal ones, I have come to wonder about file permissions...
my cvs repository belongs to the "src" group, so I add users to that
group if they should have access to the repository. (They already have
ssh access, at this moment, at a later time I might consider pserver if
I want to add people to the project that shouldn't have a shell
account...)

Now I wonder, as any of those users can modify any file in this
structure, is "trust" the only way I can stop them from messing with my
other projects? (Must I create a second repository with different "group
ownership" for this?) Secondly, with any user being able to modify
CVSROOT, as what user does the commands get executed, e.g. commit mails
from commitinfo... these run as the user doing the commit I assume? That
means any user can cause any other user to run an arbitrary command as
himself... ?

Thanks,
Hugo van der Merwe

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is there a way to retain file permissions in a workspace?

[Greg A. Woods]

[ On Thursday, February 22, 2001 at 16:32:35 (-0600), Doug Newton wrote: ]
> Subject: Is there a way to retain file permissions in a workspace?
>
> We are running pserver CVS 1.11 on a linux server.  We have a module
> in which all files and directories were imported with full permission
> given to the group level.  The archive internally reflects these
> permissions.
> 
> We have a "public" workspace that we would like muliple users in the
> group to be able to run updates on just for a refresh.
> 
> Unfortunately the user who checked the workspace out is the only one
> with full permission in the workspace.  Is there any way to create a
> workspace that will retain the archive directory/file permissions?

"Public workspaces" are an oxymoron in CVS.

You might try creating a workspace that's owned by some unique user-id
that's never used by a human user, and which is automatically updated
with a periodic (cron) job.

The real solution though is "Don't Do That!"  :-)


> Please respond directly, as I am not currently subscribed to the
> mailing list.
>
> Thanks in advance for your help.
> --Doug Newton
> [EMAIL PROTECTED]
> 
> 

Please don't ever send multi-part HTML crud to public lists.

Wrapping text at <= column 72 is also a nice thing to do

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Is there a way to retain file permissions in a workspace?

[Doug Newton]

We are running pserver CVS 1.11 on a linux server.  We 
have a module in which all files and directories were imported with full 
permission given to the group level.  The archive internally reflects these 
permissions.
 
We have a "public" workspace that we would like muliple 
users in the group to be able to run updates on just for a refresh.
 
Unfortunately the user who checked the workspace out is the 
only one with full permission in the workspace.  Is there any way to create 
a workspace that will retain the archive directory/file 
permissions?
 
Please respond directly, as I am not currently subscribed to 
the mailing list.
 
Thanks in advance for your help.
--Doug Newton
[EMAIL PROTECTED]

[robert@namodn.com: Re: newbie, WinCVS file permissions]

[Rob Helmer]

Sorry, the below should be '"Globals" tab', not '"Globals" 
tag'..  don't want to steer you wrong :)

- Forwarded message from Rob Helmer <[EMAIL PROTECTED]> -

Hello,


This is an option in the WinCVS preferences. There's
a "Checkout read-only" toggle in the "Globals" tag.

Although, this CAN be desirable behavior. You can
check out the sources read-only, and then right
click on an individual file, go to "Monitors->Edit
Selection", ( or click the pencil on the toolbar )

This will set a watch on the file, so other developers
can see if you have it checked out..



HTH,
Rob Helmer
Namodn

On Mon, Feb 05, 2001 at 03:38:08PM +0100, Kovacs Zoltan wrote:
> Hello, I'm new to the list. I downloaded the latest WinCVS, it works with
> a Linux CVS system with password authentication. It works well, but I
> always get the checkouted files read only. Where to modify the
> configuration to change this?
> 
> TIA, Zoltan
> 
> Kova'cs Zolta'n
> assistant teacher at Bolyai Institute
> [EMAIL PROTECTED]
> http://www.math.u-szeged.hu/~kovzol
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


- End forwarded message -

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: newbie, WinCVS file permissions

[Rob Helmer]

Hello,


This is an option in the WinCVS preferences. There's
a "Checkout read-only" toggle in the "Globals" tag.

Although, this CAN be desirable behavior. You can
check out the sources read-only, and then right
click on an individual file, go to "Monitors->Edit
Selection", ( or click the pencil on the toolbar )

This will set a watch on the file, so other developers
can see if you have it checked out..



HTH,
Rob Helmer
Namodn

On Mon, Feb 05, 2001 at 03:38:08PM +0100, Kovacs Zoltan wrote:
> Hello, I'm new to the list. I downloaded the latest WinCVS, it works with
> a Linux CVS system with password authentication. It works well, but I
> always get the checkouted files read only. Where to modify the
> configuration to change this?
> 
> TIA, Zoltan
> 
> Kova'cs Zolta'n
> assistant teacher at Bolyai Institute
> [EMAIL PROTECTED]
> http://www.math.u-szeged.hu/~kovzol
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

newbie, WinCVS file permissions

[Kovacs Zoltan]

Hello, I'm new to the list. I downloaded the latest WinCVS, it works with
a Linux CVS system with password authentication. It works well, but I
always get the checkouted files read only. Where to modify the
configuration to change this?

TIA, Zoltan

Kova'cs Zolta'n
assistant teacher at Bolyai Institute
[EMAIL PROTECTED]
http://www.math.u-szeged.hu/~kovzol


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions when adding directories via pserver

[Larry Jones]

Matt Munz writes:
> 
> When a user logs in to cvs via pserver and adds a directory, what
> determines the file permissions of that
> directory?  What determines the ownership, read, and write settings,
> etc.?

The operating system.  On BSD Unix (where CVS grew up), the directory
would inherit the ownership and permissions of its parent directory.  On
AT&T Unix, it would be owned by the user that created it and have
his/her default permissions.  On Linux (and other hybrid systems), you
get AT&T behavior by default, but can get BSD behavior by setting the
sgid bit on the parent directory.

-Larry Jones

Everybody's a slave to routine. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions when adding directories via pserver

[Dave Sherohman]

On Wed, Dec 20, 2000 at 03:13:55PM -0500, Matt Munz wrote:
> I am currently having the problem that one user cannot check out a directory 
>made by another, due to conflicting permissions.  After pouring over the CVS 
>manual(s) with little success, I thought I'd see if any of you could help.

Make the root directory of the CVS repository owned by group 'cvs',
group-writable, and sgid.  Make all your CVS users members of the cvs group.
Like so:

drwxrwsr-x  46 root cvs  4096 Dec 20 16:19 cvs/

The important part is that the repository's root directory must be sgid.
This will cause all files and directories created within it to inherit the
same groups settings (owned by group cvs, group-writable, and sgid).  Any
user in the cvs group will then be able to modify files in the repository.

-- 
The Shortest Windows Manual:  "Turn off the power switch."
Geek Code 3.1:  GCS d? s+: a- C++ UL++$ P++>+++ L+++> E- W--(++) N+ o+
!K w---$ O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv b+ DI D G e* h+ r y+

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

file permissions when adding directories via pserver

[Matt Munz]

Hi all.
 
    It's me again with another 
mundane question...
 
    When a user logs in to cvs via 
pserver and adds a directory, what determines the file permissions of that 

directory?  What determines the ownership, 
read, and write settings, etc.?  
 
    I am currently having the 
problem that one user cannot check out a directory made by another, due to 
conflicting permissions.  After pouring over the CVS manual(s) with little 
success, I thought I'd see if any of you could help.
 
    I'd greatly appreciate any 
assistance that anyone is willing to give.
 
    - Matt Munz
  [EMAIL PROTECTED]

Re: File permissions after checking in

[Derek R. Price]

"YEO CHUN GUAN, PSSD" wrote:

> How do I preserve my file permission when I import them into my repository?
> After importing, they all become
> executable (rwxr-xr-x)

Executable bits will be preserved.  CVS has other reasons to play with the read
and write bits.  I'd recommend building the chmod command into your build
script.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
All those who believe in psychokinesis raise my hand.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

File permissions after checking in

[YEO CHUN GUAN, PSSD]

How do I preserve my file permission when I import them into my repository?
After importing, they all become
executable (rwxr-xr-x)


This communication contains confidential or privileged information. If you
are not the intended recipient, please notify us IMMEDIATELY that you have
received it and destroy it.   We are not liable for any unauthorised sending
of or interference with this communication. 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: file permissions with client/server

[Derek R. Price]

You can play with the CVSUMASK environment variable.  I'm not completely
sure how it works.  See the manual.

Derek

--
Derek Price  CVS Solutions Architect
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
151. H lp! S m b d st l ll th v w ls fr m m k yb rd!





Mark Whitehouse wrote:

> Does anyone know how to set the directory permissions using client/server
> cvs to a specific value when directories are created with the cvs import
> command.  I am running cvs 1.10.8 on a Linux RH 6.2 server.
>
> Thanks,
> Mark

file permissions with client/server

[Mark Whitehouse]

Does anyone know how to set the directory permissions using client/server
cvs to a specific value when directories are created with the cvs import
command.  I am running cvs 1.10.8 on a Linux RH 6.2 server.

Thanks,
Mark

Re: File Permissions

[Dave Sherohman]

On Tue, May 23, 2000 at 11:38:03AM -, [EMAIL PROTECTED] wrote:
> Does any body know of any work-arounds ?

Set the permissions on the files in the repository to what you want the
working copies to have.  I assume this will work for directories also.

When adding new files, ensure that they have the correct permissions before
their first commit.  (I initially set up the repository here from files
stored on a smbmounted FAT16 drive.  One of these days, I hope to finish
taking 'execute' permissions off all the source files...)

-- 
The Shortest Windows Manual:  "Turn off the power switch."
Geek Code 3.1:  GCS d- s+: a- C++ UL++$ P+>+++ L++> E- W--(++) N+ o+ !K
w---$ O M- !V PS+ PE Y+ PGP t 5++ X+ R++ tv- b++ DI D G e* h+ r++ y+

Re: File Permissions

[Noel L Yap]

1. Set your umask to whatever suits your environment.  (I set mine to 027 'cos
I'm paranoid).
2.  Are the execute bits set on the scripts' archives?  If not, chmod +x the
scripts' archives and, in the future, be sure these bits are set before you
check them in.

Also, you should be using the latest stable release, cvs-1.10.8.  It should be
available from cyclic.com.

Noel




[EMAIL PROTECTED] on 05/23/2000 07:38:03 AM

To:   [EMAIL PROTECTED]
cc:   (bcc: Noel L Yap)
Subject:  File Permissions




Hi,

We are using CVS 1.10 in client/server mode on SOLARIS

We are facing two problems :
(1) When we checkout, the directories have rwxrwxrwx permissions. We
do not want others to have write permissions.
(2) We have few shell scripts. When we checkout these scripts, we do
not get back execute permissions.

Does any body know of any work-arounds ?
Please let me know.

Regards,

Mandar
<[EMAIL PROTECTED]>







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 & Co. Incorporated, its
subsidiaries and affiliates.

File Permissions

[mandarb]

Hi,

We are using CVS 1.10 in client/server mode on SOLARIS

We are facing two problems :
(1) When we checkout, the directories have rwxrwxrwx permissions. We 
do not want others to have write permissions.
(2) We have few shell scripts. When we checkout these scripts, we do 
not get back execute permissions.

Does any body know of any work-arounds ?
Please let me know.

Regards,

Mandar
<[EMAIL PROTECTED]>

Help needed: File permissions NT and Unix

[Paul Foster]

 I hope this hasn't been asked a million times before but I can really
use some help.
 
 I have a Sun Workstation using SunOS 5.6 running Samba 2.6. I have
shared a directory for my CVSROOT. I can successfully mount and modify
and checkin and checkout files using cvs from my NT workstation and all
seemed to be okay.
 I am using the directory as a :local:/repositorydir. I am NOT usign
pserver.

 The problem comes when I try to modify a file checked in from someone
else. The permissions set in the repository are:
 
 drwxrwxr-x mylogin mygroup myfolder // the folder
|
|-  -r--r--r-- otherlogin mygroup
otherfile,v 

 where mylogin is my login name, mygroup is my group name, same for
Samba and Unix, and my folder is the module folder.
 and otherlogin is the other persons login namd and otherfile,v is the
file he checked in.

 When on Unix cvs commit somehow changes or overrides the permissions
and allows me to go ahead and checkin. On NT however cvs commit gives
me the follwing error.  ,otherfile, cannot be renamed to otherfile,v
and commit fails.

 I have tracked it down to the following. Samba does not currently
allow me to chmod, rename, del, rm(gnu-tool), any file that is
-r--r--r-- and owned by someone other than myself. 

 I have also found that if I can set permissions to -rw-r--r-- on the
file owned by someone else Samba allows me to modify this file and
everything is okay.

 Currently I am trying to get the permissions set in the repository to
default to -rw-r--r-- and have tried everything I can think of. I have
set all combinations of umask and CVSUMASK and PerservePermissions= in
the $CVSROOT/CVSROOT/config file. Nothing seems to let me create a file
in the repository this way.

 I have tried getting Samba to let me modify this type of file (
-r--r--r-- otherlogin ) with no avail. If someone knows how to do this
that would be great also.
 
 Thanks in advance,
 Paul