From owner-freebsd-hackers Fri May 19 17:53:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 590E737BF6E for ; Fri, 19 May 2000 17:53:13 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-117-18.bellatlantic.net [151.198.117.18]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA23568; Fri, 19 May 2000 20:53:03 -0400 (EDT) Message-ID: <3925E1F6.1D5F02CE@bellatlantic.net> Date: Fri, 19 May 2000 20:53:10 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Jonathan Laventhol Cc: freebsd-hackers@freebsd.org Subject: Re: System management with large groups References: <39255860.FC0F2688@imagination.co.uk> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Laventhol wrote: > > Dear FreeBSD Hackers -- > > I've got a technically-straightfordward but nonetheless > business-critical problem with the groups structures in FreeBSD > which perhaps you kind souls can help me with. > We currently use FreeBSD 3.3-RELEASE through 4.0-RELEASE via > Walnut Creek CDs for DNS, e-mail, web, ftp, various proxies, > tacacs and a number of custom web-delivered databases. There > are maybe 15 small FreeBSD machines doing these jobs. Only > systems management actually log in on the machines, the real > users have NOLOGIN shells. > > We do not currently use NIS but I'm considering it. last time I did something like this was a few years ago with FreeBSD 2.1 but I hope that my comments may be still useful. > I am looking at the technical feasibility of moving to FreeBSD > with Samba and Netatalk. Another approach would be to modify Samba and Netatalk to check the permissions for net users by itself, without bringing this burden to OS. > *** ISSUES *** > > The most significant issue is the limits on groups. Part of this > is because of the inherent limits of user-group-world masks versus > ACLS -- which we can live with and would help us by simpifying > the problems -- and part is because of long-legacy limits within > 4.4bsd. You may want to look at "poor man's ACLs" http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14584 They are not really ACLs but IMHO are useful. > Because of the size and structure of my company a person might need to > be in 20 or 30 groups anyway. > > Because of working around the ACL issue, we'd need to have a large > number > of groups -- perhaps thousands -- and individual users in large > proportion > of those. Some users might even be in *every* group. "In every group" in your case means thousands of groups, not 20 to 30. This may be the real problem. > *** APPARENT CAUSES *** > > 1. I see that the 200-users-per-group limit is gone since 3.0-RELEASE. Was there such a limit ? As far as I remember there are limits for the number of groups in each line of /etc/group and number of characters in each line of /etc/group. But there may be multiple lines in /etc/group (that's true for any kind of Unix except possibly Linux) corresponding to a group. For example: somegroup:*:200:user1,user2,user3 somegroup:*:200:user4,user5,user6 So circumventing these limits is easy. > 2. I'm concerned about the 1+16 groups-per-user issue You can increase that easily. I think NGROUPS is what you need but I can't remember now exactly. I increased that to something like 50 without any problems. But making it equal to a few thousands may be a problem. Or maybe not. Try and see. Of course, it will cause somewhat higher memory consumption and CPU expenses but it may be not that bad. > 3. I'm concerned about large numbers of groups in a flat group(5) file. It may be a bit slow but should not cause any other problems. > *** QUESTIONS *** > > Question 0: Is this a sensible way to solve my access rights > issues? Anybody got a better way altogether? (Maybe just > hack Samba?) Yes, hacking Samba looks like a good solution. > Question 2: What is the relationship between hard-coded NGROUPS > and NGROUPS_MAX, and the sysctl kern.ngroups? NGROUPS is defined to be equal to NGROUPS_MAX. Probably kern.ngroups allows to limit the actual maximal number lower than NGROUPS_MAX. > Question 3: Can I just edit NGROUPS_MAX somewhere and make it Yes. Probably in /sys/sys/syslimits.h. > bigger? Which one do I fix? (Is there a 'make world faq? Never > done it before.) I can't say for sure but most probably you don't need to make world. Just rebuild the kernel and that has a good chance to fix it. Maybe you will also need to rebuild Samba. > Question 4: What do people think might break? Would it be better, > worse, or impossible to do this with NIS? Personally I don't believe in NIS. But NIS may be better in the sense that it uses indexed files instead of /etc/groups, so the searches in them will be fatre. > Question 5: Has anybody done anything like a vigr (like vipw) > for /etc/group? Our (locally-written) user database would be > changing the groups all the time. I think FreeBSD still has no binary indexed file for /etc/group, unlike /etc/master.passwd. So you can just edit /etc/group with vi. It also gives warnings when multiple people try to edit the same file at once. One of the things that I think would be good to implement is the ability to create hierarchies of groups. Say, create a file /etc/metagroups containing: ... group1:*:1000:user1,user2,user3 group2:*:1001:user2,*group1,user4 group3:*:1002:user5,*group2 ... Meaning that group2 also contains all the users from group1 and group3 contains all the users from group2. This file after running some Perl-based or shell-based converter would generate /etc/group containing: ... group1:*:1000:user1,user2,user3 group2:*:1001:user2,user4,user1,user3 group3:*:1002:user5,user2,user4,user1,user3 ... That should be easy enough to implement, just I never got to it. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message