info-cvs
[Top][All Lists]
Advanced

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

RE: Locks on CVS


From: Jennifer Hamilton
Subject: RE: Locks on CVS
Date: Wed, 8 Aug 2001 12:56:31 -0700

> The real solution is probably to tell Linux's silly one-group-per-user
> system to go blow 

Linux supports multiple groups per user. However, it doesn't support
multiple groups per group on the system level. If you don't have an NIS
server, try using OpenLDAP authentication via PAM (if you use ssh
authentication) to mulit-layer your groups. I'm currently working on
setting up this type of system. 

Jen


-----Original Message-----
From: gabriel rosenkoetter [mailto:address@hidden
Sent: Tuesday, August 07, 2001 10:37 PM
To: address@hidden
Cc: Sven Fischer; Derek R. Price
Subject: Re: Locks on CVS


On Tue, Aug 07, 2001 at 12:51:51PM -0400, Derek R. Price wrote:
> I'm not totally sure I understand what you're asking, but you might be
> looking for the setgid bit.  Something like, `find $CVSROOT -type d
|xargs
> chmod g+s' should do the trick.
> 
> Use at your own risk and all that.  Reading the fine man pages on
chmod (re,
> in particular, setgid) might help too.

I'm not sure this will actually fix anything under Linux, as I don't
recall whether or not it (well, actually ext2fs) actually Does the
Right Thing wrt setgid bits on directories and file (re)creation.
I have a sinking feeling it does not, though. Even if it does,
isn't CVS doing something explicit here to change ownership if it
changes merely by running cvs edit as a client?

The real solution is probably to tell Linux's silly one-group-per-user
system to go blow (which won't fix everything, since the locked or
cvs edited files will get chgrp'ed to your standard users group, but
at least it won't leave you with files useable only by a single user),
then either institute some newgrp (or does Linux use sg?) usage in
your users' .login files on the cvsroot or perform some truly evil
magic in ${CVSROOT}/CVSROOT/loginfo. Actually, this isn't hard;
it'd be easy to keep track of what group should own which module,
and which module a file has just been checked into is readily
available to something called from loginfo. If it isn't readily
evident when you look at how loginfo works, drop me a line (privately)
and I'll whack out some pseudo-(read, Perl)code to do it.

Actually, if you do the loginfo dance, you probably don't need to go
and change Linux's brain damaged grouping system. But you should
anyway. ;^>

-- 
       ~ g r @ eclipsed.net

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs



reply via email to

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