Manuel Elgorriaga Kunze
2002-Jan-09 12:03 UTC
How usernames in large Unix-groups are read in...
Hello, I really had a long time finding out about the following "feature". I've set up a Samba 2.2.3-pre fileserver (no NIS and no winbind, yet) on SuSE-Linux 7.3 with Kernel 2.4.16, with quite a complex structure (at least for me) for our 100 users, distributed along 40 Unix-groups, each user belonging to several groups; these groups are mainly intended for granting specific permissions on over 30 samba-shares, combinig Unix-file and -dir modes with the samba-specific parameters like valid users, read list, write list, force group etc. It worked fine in the test environment with a few users, but implementing it in the production environment, I didn't get but few users to authenticate to the shares, reproduceably, but without observing any systematic error behind this behaviour. After looking at the logs with Debug 10 and the code in username.c and util_getent.c, I got the reason: my /etc/group file splits groups with lots of users on several lines: groupA:x:1105:user1,user2,...,user20 groupA:x:1105:user21,...,user40 groupA:x:1105:user41,...,user37 and so on. It's mainly for clarity and editing purposes, an it did work fine with all other Linux-applications up to now. But the samba routine "add_member_to_userlist" seems to expect all group-members being on exactly one line, otherwise it just takes only the users of the first line, but without the last one on this same line. Perhaps I'm wrong, and this is a basic Unix rule, but I don't remember having read or heard anywhere, that multiple lines defining users for the same group would be illegal, and in fact, it worked in other situations. I'm sorry if this is an obvious remark; if not, perhaps it could get included in the code or at least mentioned in the man-pages. Thank you for any comment about this, Manuel --- Manuel Elgorriaga Kunze, IT Department Swiss Library for the Blind and Visually Impaired CH - 8047 Zurich, Switzerland Phone: + 41 1 491 25 55, Fax: + 41 1 492 64 75
On Wed, Jan 09, 2002 at 08:58:50PM +0100, Manuel Elgorriaga Kunze wrote:> Hello, > > I really had a long time finding out about the following "feature". I've set > up a Samba 2.2.3-pre fileserver (no NIS and no winbind, yet) on SuSE-Linux > 7.3 with Kernel 2.4.16, with quite a complex structure (at least for me) for > our 100 users, distributed along 40 Unix-groups, each user belonging to > several groups; these groups are mainly intended for granting specific > permissions on over 30 samba-shares, combinig Unix-file and -dir modes with > the samba-specific parameters like valid users, read list, write list, force > group etc. > > It worked fine in the test environment with a few users, but implementing it > in the production environment, I didn't get but few users to authenticate to > the shares, reproduceably, but without observing any systematic error behind > this behaviour. After looking at the logs with Debug 10 and the code in > username.c and util_getent.c, I got the reason: my /etc/group file splits > groups with lots of users on several lines: > > groupA:x:1105:user1,user2,...,user20 > groupA:x:1105:user21,...,user40 > groupA:x:1105:user41,...,user37 > > and so on. It's mainly for clarity and editing purposes, an it did work fine > with all other Linux-applications up to now. But the samba routine > "add_member_to_userlist" seems to expect all group-members being on exactly > one line, otherwise it just takes only the users of the first line, but > without the last one on this same line. > > Perhaps I'm wrong, and this is a basic Unix rule, but I don't remember > having read or heard anywhere, that multiple lines defining users for the > same group would be illegal, and in fact, it worked in other situations. I'm > sorry if this is an obvious remark; if not, perhaps it could get included in > the code or at least mentioned in the man-pages.Yes, this was a misconception in Samba that has now been fixed in the 2.2.x and HEAD cocdebase. The lines you describe should work with Samba 2.2.3 and all future versions. Thanks, Jeremy.