lkml.org 
[lkml]   [2002]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BK PATCH 1/4] fix NGROUPS hard limit (resend)
    On Fri, Oct 25, 2002 at 12:34:20PM +0300, Panu Matilainen wrote:
    > On Tue, 22 Oct 2002, Tim Hockin wrote:
    >
    > > Jesse Pollard wrote:
    > >
    > > > Does it actually work with NFS???? or any networked file system?
    > > > Most of them limit ngroups to 16 to 32, and cannot send any data
    > > > if there is an overflow, since that overflow would replace all of the
    > > > data you try to send/recieve...
    > >
    > > NFS has a smaller limit, that is correct. An unfortunate limitation.
    >
    > This is a real, if not terribly common problem here too. Thanks for
    > addressing the issue...

    Now i'll poke my stick into the hornets nest...

    What i think would be much more usefull and could be
    supported by NFS et al would be to allow groups to be
    members of other groups.

    Method 1 -- explicitly:

    example group file extract:
    webroot:x:103:www,jim,joy
    custadm:x:140:%webroot,bob,carol,ted,alice
    webcusts:x:1000:%webcust1,%webcust2,%webcust3
    webcust1:x:1001:%custadm,%custwebs,Matt,Christoph
    webcust2:x:1002:%custadm,%custwebs,Suparna,Aaron,Tim
    webcust3:x:1003:%custadm,%custwebs,Randal,Jesse

    I'm using the % prefix here to specify the group
    namespace.

    It would require permissions checking to aquire a
    list of groups that are group members.

    Now, changing it at this level would require that
    the libs be updated (but so would infinite groups)
    and a way to inform the kernel of the nested group
    memberships.

    For informing the kernel i lean toward a sysfs
    interface fed by a user-space utility that would
    build or update a pinned table. The in-kernel group
    lists would be unrolled (per the example
    webroot=custadm,webcust1,webcust2,webcust3)

    There would be problems with existing utilities due
    to the new logic but that is a fairly small set and
    it might not be unreasonable to provide an infinite
    NGROUPS emulation. Also multiple inheritance and
    loops would have to be caught.

    It also provides a way to have 400 (out of 16000)
    users in a group without infinite line length in
    /etc/group.

    Method 2 -- implicitly:

    Have the sysfs interface fed by a utility that would
    use a separate config file. The group file would be
    constructed as though NGROUPS were infinite.

    When setgroups is called with size > NGROUPS
    it would have to search for any entries that
    matched the list (yuck). Match failure would
    error with EINVAL

    The only change to libs and utilities would be to
    lift NGROUPS_MAX. The need for explicity group
    numbers would be so it would work over networks.

    This method has far too much magic for my taste and
    the potential for admin error in maintaining
    separate files is frightening.

    The implicit method could be restricted to an
    extension to NFS but then you would need to have the
    match cached in task_struct (reset by setgroups).

    The important thing either way would be that you would save
    on memory for group lists and it would work over NFS without
    a protocol change.

    I've actually wanted the nested group memberships for a long
    time.

    The only other idea I've had for accommodating NFS and other
    remote FS for processes having excessive NGROUPS is to have
    the client fetch the ownership and ACLs and execute the
    access specifying the applicable subset of groups. This
    would not be good for performance but might possibly be done
    with the existing protocols and might be better
    performance-wise than sending kilobytes of GIDs with every
    RPC call.




    --
    ________________________________________________________________
    J.W. Schultz Pegasystems Technologies
    email address: jw@pegasys.ws

    Remember Cernan and Schmitt
    -
    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:3.349 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site