[gui-dev] CVS lockup in the gui module for its themes folder - bad access rights

[Philippe Verdy]

I can't update the GUI module completely, because of strange bad access
rights for a lock folder used in CVS:

cvs server: Updating com/limegroup/gnutella/gui/themes
cvs server: failed to create lock directory for
`/cvs/gui/com/limegroup/gnutella/gui/themes'
(/usr/local/tigris/data/helm/cvs/lock/gui/com/limegroup/gnutella/gui/themes/#cvs.lock):
Permission denied
cvs server: failed to obtain dir lock in repository
`/cvs/gui/com/limegroup/gnutella/gui/themes'
cvs [server aborted]: read lock failed - giving up

Apparently, the .../cvs/lock/... directory was created by the wrong user,
and denies access to users in the group normally granted update accesses to
the GUI module.

(note that the user "guest" is part of that group which should be able to
get locks to perform updates, even if it is not granted
additions/deletions/commit)

Because of this lock, that occurs only for that subfolder, the following
folders after "/gui/themes" are not updated, and must be updated
separately... This is new, because in the past even "guest" could update its
sources...

Only LimeWire admins can correct this by checking the Unix folder ownerships
and access rights in the cvs/lock folder indicated above.

[Sam Berlin]

Fixed now -- I believe it's a problem with the way CVS creates new
directories.

Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 2:23 PM
Subject: [gui-dev] CVS lockup in the gui module for its themes folder -
badaccess rights
I can't update the GUI module completely, because of strange bad access
cvs server: Updating com/limegroup/gnutella/gui/themes
cvs server: failed to create lock directory for
`/cvs/gui/com/limegroup/gnutella/gui/themes'
(/usr/local/tigris/data/helm/cvs/lock/gui/com/limegroup/gnutella/gui/theme
Permission denied
cvs server: failed to obtain dir lock in repository
`/cvs/gui/com/limegroup/gnutella/gui/themes'
cvs [server aborted]: read lock failed - giving up
Apparently, the .../cvs/lock/... directory was created by the wrong user,
and denies access to users in the group normally granted update accesses to
the GUI module.
(note that the user "guest" is part of that group which should be able to
get locks to perform updates, even if it is not granted
additions/deletions/commit)
Because of this lock, that occurs only for that subfolder, the following
folders after "/gui/themes" are not updated, and must be updated
separately... This is new, because in the past even "guest" could update its
sources...
Only LimeWire admins can correct this by checking the Unix folder ownerships
and access rights in the cvs/lock folder indicated above.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Michael D. Hirsch]

Post by Sam Berlin
Fixed now -- I believe it's a problem with the way CVS creates new
directories.

Sounds like you may have the CVS directories misconfigured. Everyone
with write permission should be in a group and that group should own all
the files. The way to do this is to create the top dir with the right
group ownership and 2775 permissions.

If you don't have this, first change the ownership:
chgroup -R groupname topdirname
Now, change the guid bit set on the directories. Assuming that you are
using a unix server for CVS, the guid bit of the CVS directories should
be set. Use "chmod g+s directory" for a single directory. A quick
script or find invocation will be needed to set it in every directory.

The point of the guid bit is that it means any file or dir created in the
guid directory will be owned by the same group, so this problem won't
reoccur.

Of course, I could be reading a lot or hooey into your one line account
and be totally off base, here. If so, then please ignore me. :-)

Michael

Post by Sam Berlin
Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 2:23 PM
Subject: [gui-dev] CVS lockup in the gui module for its themes
folder - badaccess rights
I can't update the GUI module completely, because of strange bad
cvs server: Updating com/limegroup/gnutella/gui/themes
cvs server: failed to create lock directory for
`/cvs/gui/com/limegroup/gnutella/gui/themes'
(/usr/local/tigris/data/helm/cvs/lock/gui/com/limegroup/gnutella/gui
Permission denied
cvs server: failed to obtain dir lock in repository
`/cvs/gui/com/limegroup/gnutella/gui/themes'
cvs [server aborted]: read lock failed - giving up
Apparently, the .../cvs/lock/... directory was created by the wrong
user, and denies access to users in the group normally granted
update accesses to
the GUI module.
(note that the user "guest" is part of that group which should be
able to get locks to perform updates, even if it is not granted
additions/deletions/commit)
Because of this lock, that occurs only for that subfolder, the
following folders after "/gui/themes" are not updated, and must be
updated separately... This is new, because in the past even "guest"
could update its
sources...
Only LimeWire admins can correct this by checking the Unix folder ownerships
and access rights in the cvs/lock folder indicated above.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Sam Berlin]

Hi Michael,

Thanks very much for the information on fixing up CVS. Our situation is
somewhat more unique in that we want to provide different access rights for
different modules. Philippe Verdy, for instance, has privileges to write to
the 'lib' module, as he provides excellent contributions and maintenance for
internationalizing LimeWire. Roger Kapsi also has privileges to the 'daap'
module, which is more or less his code that we're providing a public CVS
repository for (and is incorporated in to LimeWire). These and all the
other modules (core, gui, tests, etc...) are writable by us LimeWire folk.
To do this, we have special groups ('cvs-lib' and 'cvs-daap' that those
modules are owned by (and those users belong to), whereas all the others
ones belong to 'cvs'. Will your scheme still work, providing we set the
sticky bits appropriately in each respective module? It seems now that the
directories are created with the uid of the cvs user that creates them.

Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 10:19 PM
Subject: Re: [gui-dev] CVS lockup in the gui module for its themes folder
-badaccess rights

Post by Sam Berlin
Fixed now -- I believe it's a problem with the way CVS creates new
directories.

Sounds like you may have the CVS directories misconfigured. Everyone
with write permission should be in a group and that group should own all
the files. The way to do this is to create the top dir with the right
group ownership and 2775 permissions.
chgroup -R groupname topdirname
Now, change the guid bit set on the directories. Assuming that you are
using a unix server for CVS, the guid bit of the CVS directories should
be set. Use "chmod g+s directory" for a single directory. A quick
script or find invocation will be needed to set it in every directory.
The point of the guid bit is that it means any file or dir created in the
guid directory will be owned by the same group, so this problem won't
reoccur.
Of course, I could be reading a lot or hooey into your one line account
and be totally off base, here. If so, then please ignore me. :-)
Michael

Post by Sam Berlin
Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 2:23 PM
Subject: [gui-dev] CVS lockup in the gui module for its themes
folder - badaccess rights
I can't update the GUI module completely, because of strange bad
cvs server: Updating com/limegroup/gnutella/gui/themes
cvs server: failed to create lock directory for
`/cvs/gui/com/limegroup/gnutella/gui/themes'
(/usr/local/tigris/data/helm/cvs/lock/gui/com/limegroup/gnutella/gui
Permission denied
cvs server: failed to obtain dir lock in repository
`/cvs/gui/com/limegroup/gnutella/gui/themes'
cvs [server aborted]: read lock failed - giving up
Apparently, the .../cvs/lock/... directory was created by the wrong
user, and denies access to users in the group normally granted
update accesses to
the GUI module.
(note that the user "guest" is part of that group which should be
able to get locks to perform updates, even if it is not granted
additions/deletions/commit)
Because of this lock, that occurs only for that subfolder, the
following folders after "/gui/themes" are not updated, and must be
updated separately... This is new, because in the past even "guest"
could update its
sources...
Only LimeWire admins can correct this by checking the Unix folder ownerships
and access rights in the cvs/lock folder indicated above.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Philippe Verdy]

Michael is right: setting the "g+s" access right to a parent dir means that
all filenames or direcories added in that parent directory will inherit the
group-ownership from the parent dir, instead of acquiring the
group-ownership of the user that creates that file or directory.
You may as well use "u+s" (combinable in chown with "gu+s") if you want also
to inherit of the uid of the parent directory (avoiding other headaches if
one file initially created by one user in one group is then read by other
users in that group, but the user is later changed to another group).
The best solution is then to create a user with the name of the group that
must haves write-privileges to a module, and then set the module directory
with the uid/gid of that user. Then you can map all normal Unix users to one
or more groups, and all files that this user will create will inherit from
the uid/gid of the parent folder.

Example:

- with the "cvs" user, uid=101, gid=101, you give ownership of the cvs
modules to:

$ mkdir cvs
$ chown -R cvs cvs
$ chgrp -R cvs cvs

$ find cvs -type d -exec chmod 775 {} \; -exec chmod gu+s {} \;
-o -type f -exec chmod 554 {} \;

- then with the "cvs-lib" user, uid=102, gif=102, you do:

$ cd cvs
$ mkdir lib
$ chown -R cvs-lib lib
$ chgrp -R cvs-lib lib

$ find lib -type d -exec chmod 775 {} \; -exec chmod gu+s {} \;
-o -type f -exec chmod 554 {} \;

Note: the -o parameter is to allow distinction between file types and
directory types, because only directories should be given the
execute(=traversal) access right to users/groups/others.

This done, all files or directories newly created in a module will remain
with the ownership and accessrights of the module owner/group: a user can
still only write if it is itself the file or directory owner or a member of
the group that owns the module. All creations are immediately given to the
module owner and group; files can still be written by that user despite it
is no longer the owner itself and despite it is the user that created that
file.

If you prefer that files' user-ownership remain that user, you can just keep
the "group inherit" attribute (g+s) on directories. You may also want that
the file may not be deletable by all members of the modules' group, but only
by that user by adding the "u+t" attribute, i.e. the user-sticky bit, (this
is what is normally configured in /tmp, so that anyone can write in that
directory, but only the owner of the file can unlink it from the /tmp
directory, and nobody else can overwrite the temporary files created by that
user, unless that user gives the permission in his file)

----- Original Message -----
From: "Sam Berlin" <***@limepeer.com>
To: <***@gui.limewire.org>
Sent: Saturday, November 27, 2004 7:39 AM
Subject: RE: [gui-dev] CVS lockup in the gui module for its themes
folder-badaccess rights

Post by Sam Berlin
Hi Michael,
Thanks very much for the information on fixing up CVS. Our situation is
somewhat more unique in that we want to provide different access rights for
different modules. Philippe Verdy, for instance, has privileges to write to
the 'lib' module, as he provides excellent contributions and maintenance for
internationalizing LimeWire. Roger Kapsi also has privileges to the 'daap'
module, which is more or less his code that we're providing a public CVS
repository for (and is incorporated in to LimeWire). These and all the
other modules (core, gui, tests, etc...) are writable by us LimeWire folk.
To do this, we have special groups ('cvs-lib' and 'cvs-daap' that those
modules are owned by (and those users belong to), whereas all the others
ones belong to 'cvs'. Will your scheme still work, providing we set the
sticky bits appropriately in each respective module? It seems now that the
directories are created with the uid of the cvs user that creates them.

[Michael D. Hirsch]

Yes, that scheme still works. You are perfectly setup for it--you did
the right thing by partitioning things with groups, now you just need to
add the guid bit.

Phillipe provided the 1 line find command which can be used:

chgrp -R cvs-lib lib
find lib -t d -exec chgrp 2775 cvs-lib {} \;

will make all of cvs-lib owned by the cvs-lib group and put the guid bit
on all the directories.

Michael

Post by Sam Berlin
Hi Michael,
Thanks very much for the information on fixing up CVS. Our situation
is somewhat more unique in that we want to provide different access
rights for different modules. Philippe Verdy, for instance, has
privileges to write to the 'lib' module, as he provides excellent
contributions and maintenance for internationalizing LimeWire. Roger
Kapsi also has privileges to the 'daap' module, which is more or less
his code that we're providing a public CVS repository for (and is
incorporated in to LimeWire). These and all the other modules (core,
gui, tests, etc...) are writable by us LimeWire folk. To do this, we
have special groups ('cvs-lib' and 'cvs-daap' that those modules are
owned by (and those users belong to), whereas all the others ones
belong to 'cvs'. Will your scheme still work, providing we set the
sticky bits appropriately in each respective module? It seems now
that the directories are created with the uid of the cvs user that
creates them.
Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 10:19 PM
Subject: Re: [gui-dev] CVS lockup in the gui module for its themes
folder -badaccess rights

Post by Sam Berlin
Fixed now -- I believe it's a problem with the way CVS creates new
directories.

Sounds like you may have the CVS directories misconfigured.
Everyone with write permission should be in a group and that group
should own all the files. The way to do this is to create the top
dir with the right group ownership and 2775 permissions.
chgroup -R groupname topdirname
Now, change the guid bit set on the directories. Assuming that you
are using a unix server for CVS, the guid bit of the CVS directories
should be set. Use "chmod g+s directory" for a single directory. A
quick script or find invocation will be needed to set it in every
directory.
The point of the guid bit is that it means any file or dir created
in the guid directory will be owned by the same group, so this
problem won't reoccur.
Of course, I could be reading a lot or hooey into your one line
account and be totally off base, here. If so, then please ignore
me. :-)
Michael

Post by Sam Berlin
Thanks,
Sam

-----Original Message-----
Sent: Friday, November 26, 2004 2:23 PM
Subject: [gui-dev] CVS lockup in the gui module for its themes
folder - badaccess rights
I can't update the GUI module completely, because of strange bad
cvs server: Updating com/limegroup/gnutella/gui/themes
cvs server: failed to create lock directory for
`/cvs/gui/com/limegroup/gnutella/gui/themes'
(/usr/local/tigris/data/helm/cvs/lock/gui/com/limegroup/gnutella
Permission denied
cvs server: failed to obtain dir lock in repository
`/cvs/gui/com/limegroup/gnutella/gui/themes'
cvs [server aborted]: read lock failed - giving up
Apparently, the .../cvs/lock/... directory was created by the
wrong user, and denies access to users in the group normally
granted update accesses to
the GUI module.
(note that the user "guest" is part of that group which should
be able to get locks to perform updates, even if it is not
granted additions/deletions/commit)
Because of this lock, that occurs only for that subfolder, the
following folders after "/gui/themes" are not updated, and must
be updated separately... This is new, because in the past even
"guest" could update its
sources...
Only LimeWire admins can correct this by checking the Unix folder ownerships
and access rights in the cvs/lock folder indicated above.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev