Date: Fri, 19 May 2000 20:53:10 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: Jonathan Laventhol <jonathan.laventhol@imagination.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: System management with large groups Message-ID: <3925E1F6.1D5F02CE@bellatlantic.net> References: <39255860.FC0F2688@imagination.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3925E1F6.1D5F02CE>