[OpenAFS-devel] setgroups() fails to change pag under linux 2.6

Jeffrey Hutzelman jhutz@cmu.edu
10 Aug 2006 11:20:00 -0400


Bear in mind, our primary motivation in doing something other than using groups is not to make PAG's invisible, but to have them at all.  Making the extra groups go away and solving the scarcity issue are both important but secondary goals.

--Jeff

-----Original Message-----
From: David Thompson <thomas@cs.wisc.edu>
Date: Thursday, Aug 10, 2006 10:43 am
Subject: Re: [OpenAFS-devel] setgroups() fails to change pag under linux 2.6

Roland Kuhn wrote:
>On 9 Aug 2006, at 18:16, chas williams - CONTRACTOR wrote:
>
>>> In message <FAE01A19-F876-471F-AB75-AF6D5B9C60DF@e18.physik.tu- 
>> muenchen.de>,Rol
>> and Kuhn writes:
>>> You got me curious. I should probably watched this thread more
>>> closely and maybe it would then be clear to me: Why should userspace
>>> ever see a PAG identifier? What should it be able to do with it?
>>
>> ideally, the userspace would be unaware of the pag and/or be able to
>> read/write it.  however, pags were stored in the group list which was
>> the only thing available at the time.  so users could see the pag and
>> do unwise things.  only root can change the group list so this atleast
>> kept ordinary users from manipulating their group list.
>>
>Okay, so PAG reuse should not be an issue, right? :-) If you do  
>"unwise things", you get to keep the pieces.
>
>The problem (in our eyes) that brought all this up was the relative scarcity 
>of pags over the execution time of the kernel.  I would love to have pags made 
>invisible, provided that the current restrictions on obtaining them be 
>eliminated.  To repeat for emphasis: it is the scarcity of pags, not how they 
>are stored, that is the real issue for us.  To make them invisible without 
>solving the scarcity problem leaves us with our original problem while taking 
>away our workaround.
>
>I would have no desire or need to reuse pags if there were 
>"unlimited||sufficient" pags in the first place.  If I could obtain a new pag 
>at will, without concern that I'm going to run out of pags or have performance 
>issues, I would welcome a solution that would get the current overloading out 
>of the group list.
>
>Dave
>
>
>