32 group limit

32 group limit

[Jim Kingdon]

I propose the following as a solution/workaround for the 32 group
limit:

* Create a separate anonymous CVS user for each project, rather than
  one for all projects.  This could be one anoncvs user for 32
  projects (in fact we can keep "anoncvs" for the projects which
  already have it), but one per project e.g. "anoncygwin-xfree" rather
  than "anon4" is probably clearer.

Hacking it so that CVS calls newgrp() strikes me as harder - you'd
need to find out which root you are dealing with before you switched
users, so you need to hack CVS itself rather than just putting a
script between inetd and CVS.  Not impossible (add an option to
CVSROOT/config, get the patch accepted upstream), just harder.

Re: 32 group limit

[Tom Tromey]

Jim> * Create a separate anonymous CVS user for each project, rather
Jim>   than one for all projects.

This would be annoying.  You'd have to log in once per project you are
interested in.

Jim> Hacking it so that CVS calls newgrp() strikes me as harder

What about the fix Gord posted last week?
That fix looks fairly straightforward, and is temporary until glibc is
fixed.

Tom

Re: 32 group limit

[Jeffrey A Law]

http://www.cygnus.com		http://www.cygnus.com/egcs

  In message < 200003141730.JAA04653@ferrule.cygnus.com >you write:
  > Jim> * Create a separate anonymous CVS user for each project, rather
  > Jim>   than one for all projects.
  > 
  > This would be annoying.  You'd have to log in once per project you are
  > interested in.
Does anyone know if the pserver allows you to have multiple "logins" active?

If so, you just have to cvs login to each project once and never cvs logout.


jeff

Re: 32 group limit

[Tom Tromey]

Jeff> Does anyone know if the pserver allows you to have multiple
Jeff> "logins" active?

Yes, it does.

Jeff> If so, you just have to cvs login to each project once and never
Jeff> cvs logout.

I still find it annoying, especially when we have an actual fix that
we know works.  (OTOH, I agree that the actual fix requires a kernel
rebuild, which might be impossible due to scheduling/time issues.
Bummer.)

Tom

Re: 32 group limit

[Jim Kingdon]

> OTOH, I agree that the actual fix requires a kernel rebuild, which
> might be impossible due to scheduling/time issues.  Bummer.

Running a sourceware-specific hacked up kernel is totally the wrong
solution, IMHO (just think about the extra work for future OS/kernel
upgrades to address the security hole du jour or whatever).  However,
getting this into the main kernel shouldn't be all that hard.

  echo 256 >/proc/ngroups

or something of the sort (#include standard sysctl vs. /proc flame
here).

Perhaps sourceforge already such a patch, Someone(TM) should get on
their mailing lists (or some other form of establishing contact).

Re: 32 group limit

[Ulrich Drepper]

Jim Kingdon <kingdon@redhat.com> writes:

> Running a sourceware-specific hacked up kernel is totally the wrong
> solution, IMHO (just think about the extra work for future OS/kernel
> upgrades to address the security hole du jour or whatever).

I don't agree.

>  However,
> getting this into the main kernel shouldn't be all that hard.
> 
>   echo 256 >/proc/ngroups

Nope, you will probably never get this in.  The problem is that the
structures which is sized by the NGROUPGS value is in the strcut
sched, one of the essential data structures.  There are many
consideration about the struct including alignment so that dynamic
allocation is not a good idea.  Propose it to the kernel guys but I'm
pretty sure they won't like it.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

32 group limit

[Jim Kingdon]

I propose the following as a solution/workaround for the 32 group
limit:

* Create a separate anonymous CVS user for each project, rather than
  one for all projects.  This could be one anoncvs user for 32
  projects (in fact we can keep "anoncvs" for the projects which
  already have it), but one per project e.g. "anoncygwin-xfree" rather
  than "anon4" is probably clearer.

Hacking it so that CVS calls newgrp() strikes me as harder - you'd
need to find out which root you are dealing with before you switched
users, so you need to hack CVS itself rather than just putting a
script between inetd and CVS.  Not impossible (add an option to
CVSROOT/config, get the patch accepted upstream), just harder.

Re: 32 group limit

[Jim Kingdon]

> OTOH, I agree that the actual fix requires a kernel rebuild, which
> might be impossible due to scheduling/time issues.  Bummer.

Running a sourceware-specific hacked up kernel is totally the wrong
solution, IMHO (just think about the extra work for future OS/kernel
upgrades to address the security hole du jour or whatever).  However,
getting this into the main kernel shouldn't be all that hard.

  echo 256 >/proc/ngroups

or something of the sort (#include standard sysctl vs. /proc flame
here).

Perhaps sourceforge already such a patch, Someone(TM) should get on
their mailing lists (or some other form of establishing contact).

Re: 32 group limit

[Tom Tromey]

Jim> * Create a separate anonymous CVS user for each project, rather
Jim>   than one for all projects.

This would be annoying.  You'd have to log in once per project you are
interested in.

Jim> Hacking it so that CVS calls newgrp() strikes me as harder

What about the fix Gord posted last week?
That fix looks fairly straightforward, and is temporary until glibc is
fixed.

Tom

Re: 32 group limit

[Jeffrey A Law]

http://www.cygnus.com		http://www.cygnus.com/egcs

  In message < 200003141730.JAA04653@ferrule.cygnus.com >you write:
  > Jim> * Create a separate anonymous CVS user for each project, rather
  > Jim>   than one for all projects.
  > 
  > This would be annoying.  You'd have to log in once per project you are
  > interested in.
Does anyone know if the pserver allows you to have multiple "logins" active?

If so, you just have to cvs login to each project once and never cvs logout.


jeff

Re: 32 group limit

[Ulrich Drepper]

Jim Kingdon <kingdon@redhat.com> writes:

> Running a sourceware-specific hacked up kernel is totally the wrong
> solution, IMHO (just think about the extra work for future OS/kernel
> upgrades to address the security hole du jour or whatever).

I don't agree.

>  However,
> getting this into the main kernel shouldn't be all that hard.
> 
>   echo 256 >/proc/ngroups

Nope, you will probably never get this in.  The problem is that the
structures which is sized by the NGROUPGS value is in the strcut
sched, one of the essential data structures.  There are many
consideration about the struct including alignment so that dynamic
allocation is not a good idea.  Propose it to the kernel guys but I'm
pretty sure they won't like it.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: 32 group limit

[Tom Tromey]

Jeff> Does anyone know if the pserver allows you to have multiple
Jeff> "logins" active?

Yes, it does.

Jeff> If so, you just have to cvs login to each project once and never
Jeff> cvs logout.

I still find it annoying, especially when we have an actual fix that
we know works.  (OTOH, I agree that the actual fix requires a kernel
rebuild, which might be impossible due to scheduling/time issues.
Bummer.)

Tom