lkml.org 
[lkml]   [2002]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [BK PATCH 1/4] fix NGROUPS hard limit (resend)
Date
On Tuesday 22 October 2002 03:30 pm, Mike Touloumtzis wrote:
> On Tue, Oct 22, 2002 at 03:13:41PM -0500, Jesse Pollard wrote:
> > On Tuesday 22 October 2002 02:45 pm, Mike Touloumtzis wrote:
> > > Large CVS hosting operations like GNU Savannah have historically used
> > > patches to increase NGROUPS. Using one group per project in CVS is the
> > > sanest way to manage a big repository with complex permissions.
> >
> > OK, I'll bite..
> >
> > Why is this?
>
> I only learned about this by reading the docs on Savannah; the admins can
> provide better information. But my understanding is simply that they have
> M users and N projects, and they want the system to support any number of
> permission pairs from M x N, i.e. they want each user to be able to commit
> to an arbitrary number of projects. And CVS relies on OS permissions.

Thats what I thought. Essentially, all projects are world rw if all users
have access to all projects.

> > I saw the post about having to have access to a lock directory by a
> > cvsuser, but how is that different than having that directory with an
> > ACL entry that includes the cvsuser? Or an ACL that includes the
> > group that the cvsuser is a member of?
>
> I guess they prefer to use traditional Unix permissions rather than ACLs.
> I have the same preference. Unix groups are well supported by tools and
> the kind of permission setup I described above is nicely transparent
> to administer. Granting a user write access to a project is simply
> 'adduser username projectname', and a project can easily support a large
> number of writers without big ACLs.
>
> The issue is not just lock directories, but the right to change any
> file in a project, i.e. full CVS commit access to the project rather
> than anonymous access.

As soon as everyone is in every group you get anonymous access.
You would also have the same result by putting all of the CVS files in
one group.

Or by just making the directories/files world rwx/rw.

> So they would need an ACL on each file in the
> repository, and they would need new files to inherit ACLs from their
> parent directories (I've never used ACLs on Linux but I assume this kind
> of thing is supported).

Actually it depends on the implementation. I believe some of the ACL
specs on a directory can be specified to be inherited (I'll have to check
the POSIX ACL definitions, but I remember a number of capabilities
available on directories that didn't exist for files-- yup - It's called
a "default ACL" and can be used to set UGO access, protection
masking and user acess controls).

In the scenario above, I would most likey specify an ACL to
include specific groups of users. That way it wouldn't necessarily
be equivalent to a world rw access.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.457 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site