Philippe Verdy
2004-12-04 00:46:33 UTC
Note that since today, I'm unable to even get read access to the /cvs/lib
folder, because my account on limewire.org (verdyp, uid=511, group=cvs-lib,
gid=107) is denied all accesses to /cvs (unlike the "guest" user account
which is a member of all groups...)
Something was garbled in access rights...
Normally the "guest" user should be in its own group, where it will only
have read accesses to the various folders. To do that, the cvs folders need
to be effectively owned by the module's group owner, like it is now (and
effectively kept consistent with the "g+s" group-sticky bit as it is now).
But users that are in other groups than the module's owner group should
still be given read access to files, and read/exec access to directories so
that they can be traversed.
On limewire.org, it seems that cvs folders give NO access right at all to
any user outside the file or directory owner or users in the group of the
file or directory.
Normally, there's no reason to forbid read access on these files to
"others".
The "guest" user should not need to be part of the "cvs" or "cvs-lib" or
"cvs-daap" groups. Guest just needs to be in its own default "crapuser"
group: because this group will not own any file or directory (gid), and
because "guest" will also own no file or directory (uid), he will inherit
from access rights from others (so he will have only read access on these
CVS stored files, or read/exec access to these CVS stored folders).
All the limewire team members should already be in the default group
"cvs-private", and then be listed in the "cvs" group to get full control to
CVS, but they may need to be listed also (in /etc/group) in the cvs-lib and
cvs-daap groups.
LimeWire can still, if it wishes so, keep an exclusive list of files visible
only by Limewire crew (sberlin, gbildson, jschmidt, zlatinb, mformel,
kcatillaz, tjones) by setting the container folder of their files to be
owned by someone in the "cvs-private" group, and by listing these users
within the "cvs-private" group (in /etc/group). These protected files and
folders that no one else must see should be given no access right for
"others", but only group-level access rights (read or read-write or
read-exec or read-write-exec).
Consequence: I can't update anything from the lib module. I need to logon as
guest to get at least the read access (cvs update). There's no way to change
anything (cvs add, cvs commit) when logged as "verdyp" or as "guest".
Isn't there someone trained with such basic Unix administration skills at
LimeWire?
Correction to do: restore the read access for others (chmod o+r) on files,
and read-exec access for others on directories. These have incorrectly been
set to zero:
$ cd /spare/cvs
$ chmod -R o+r .
$ find . -type d -exec chmod o+rx {} \;
Then make sure that guest is not a member of all groups that have already
given write accesses to CVS folders:
$ id guest
(normally the group of the "guest" user, uid=502, should be "crapuser",
gid=506; he will inherit of read-only access rights given to 'others' for
files and directories)
folder, because my account on limewire.org (verdyp, uid=511, group=cvs-lib,
gid=107) is denied all accesses to /cvs (unlike the "guest" user account
which is a member of all groups...)
Something was garbled in access rights...
Normally the "guest" user should be in its own group, where it will only
have read accesses to the various folders. To do that, the cvs folders need
to be effectively owned by the module's group owner, like it is now (and
effectively kept consistent with the "g+s" group-sticky bit as it is now).
But users that are in other groups than the module's owner group should
still be given read access to files, and read/exec access to directories so
that they can be traversed.
On limewire.org, it seems that cvs folders give NO access right at all to
any user outside the file or directory owner or users in the group of the
file or directory.
Normally, there's no reason to forbid read access on these files to
"others".
The "guest" user should not need to be part of the "cvs" or "cvs-lib" or
"cvs-daap" groups. Guest just needs to be in its own default "crapuser"
group: because this group will not own any file or directory (gid), and
because "guest" will also own no file or directory (uid), he will inherit
from access rights from others (so he will have only read access on these
CVS stored files, or read/exec access to these CVS stored folders).
All the limewire team members should already be in the default group
"cvs-private", and then be listed in the "cvs" group to get full control to
CVS, but they may need to be listed also (in /etc/group) in the cvs-lib and
cvs-daap groups.
LimeWire can still, if it wishes so, keep an exclusive list of files visible
only by Limewire crew (sberlin, gbildson, jschmidt, zlatinb, mformel,
kcatillaz, tjones) by setting the container folder of their files to be
owned by someone in the "cvs-private" group, and by listing these users
within the "cvs-private" group (in /etc/group). These protected files and
folders that no one else must see should be given no access right for
"others", but only group-level access rights (read or read-write or
read-exec or read-write-exec).
Consequence: I can't update anything from the lib module. I need to logon as
guest to get at least the read access (cvs update). There's no way to change
anything (cvs add, cvs commit) when logged as "verdyp" or as "guest".
Isn't there someone trained with such basic Unix administration skills at
LimeWire?
Correction to do: restore the read access for others (chmod o+r) on files,
and read-exec access for others on directories. These have incorrectly been
set to zero:
$ cd /spare/cvs
$ chmod -R o+r .
$ find . -type d -exec chmod o+rx {} \;
Then make sure that guest is not a member of all groups that have already
given write accesses to CVS folders:
$ id guest
(normally the group of the "guest" user, uid=502, should be "crapuser",
gid=506; he will inherit of read-only access rights given to 'others' for
files and directories)