lkml.org 
[lkml]   [2002]   [Oct]   [22]   [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 01:21 pm, 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.
    >
    > > And I really doubt that anybody has 10000 unique groups (or even
    > > close to that) running under any system. The center I'm at has
    > > some of the largest UNIX systems ever made, and there are only
    > > about 600 unique groups over the entire center. The largest number
    > > of groups a user can be in is 32. And nobody even comes close.
    >
    > I'm glad it doesn't affect you. If it was a more common problem, it
    > would have been solved a long time ago. It does affect some people,
    > though. Maybe they can redesign their group structures, but why not
    > remove this arbitrary limit, since we can?

    Think about a while - if a file write (say 1K in length) must include 10000
    groups (at 16 bits/group? 32bits?) then the resulting transaction becomes
    1K + 2*10K -> 21K (or 1K+4*10K -> 41K). This is over 20 times the overhead.

    No I don't expect the structures to be changed that much.

    I am in favor of being able to change the limits, but lets be reasonable.
    I can see a use for 64 groups, but not much over. Even that introduces
    a practical security problem (leakage of data from one authorized group
    to unauthorized groups).

    By the time you get one or more people with that many groups you
    may as well put everybody in one group and be done with it.

    ACLs would be much more usefull, and controllable than 10000 groups
    anyway. At least the owner of the file would be able to specify exactly
    what access is being granted, and to whom.

    BTW, a bsearch algorithm is slow compaired to a radix search in
    sparse trees...

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