sys_setgroups : migration issues from 3.0 series to 3.2/3.3 series

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

sys_setgroups : migration issues from 3.0 series to 3.2/3.3 series

miguel.sanders
Hi guys

I'm having some difficulties migrating from the 3.0 series to the
3.2/3.3 series.
The problem I am faced with considers a user which has a lot AD groups,
which crashes the 3.2/3.3 instance whereas it works perfectly fine in
the 3.0 series.
- What I am observing from the 3.0 series smbd log when the user
(sidsmig, UNIX uid 500 gid 1) connects

[2009/04/17 19:50:48, 10] auth/auth_util.c:debug_nt_user_token(454)
  NT user token of user S-1-5-21-2009150308-1095399282-1287535205-30702
  contains 144 SIDs
  SID[  0]: S-1-5-21-2009150308-1095399282-1287535205-30702
  SID[  1]: S-1-5-21-2009150308-1095399282-1287535205-93519
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-2009150308-1095399282-1287535205-15771
  ...
  SID[140]: S-1-5-21-2009150308-1095399282-1287535205-64827
  SID[141]: S-1-5-21-2009150308-1095399282-1287535205-65119
  SID[142]: S-1-5-21-2009150308-1095399282-1287535205-19378
  SID[143]: S-1-5-32-545
  SE_PRIV  0x0 0x0 0x0 0x0
  SE_PRIV  0x0 0x0 0x0 0x0
[2009/04/17 19:50:48, 5] auth/auth_util.c:debug_unix_user_token(474)
  UNIX token of user 500
  Primary group is 1 and contains 1 supplementary groups
  Group[  0]: 97
[2009/04/17 19:50:48, 5] smbd/uid.c:change_to_user(260)
  change_to_user uid=(0,500) gid=(0,1)

All this look pretty good to me. I checked all SIDs and they are
correctly linked to my AD user.

- Now when I am observing the 3.2/3.3 smbd log, I can see the following
for the same user

[2009/04/17 19:45:33, 10] auth/token_util.c:debug_nt_user_token(528)
  NT user token of user S-1-5-21-2009150308-1095399282-1287535205-30702
  contains 283 SIDs
  SID[  0]: S-1-5-21-2009150308-1095399282-1287535205-30702
  SID[  1]: S-1-5-21-2009150308-1095399282-1287535205-513
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-2009150308-1095399282-1287535205-93519
  ...
  SID[140]: S-1-5-21-2009150308-1095399282-1287535205-64827
  SID[141]: S-1-5-21-2009150308-1095399282-1287535205-65119
  SID[142]: S-1-5-21-2009150308-1095399282-1287535205-19378
  SID[143]: S-1-22-1-500
  SID[144]: S-1-22-2-500
  ...
  SID[280]: S-1-22-2-589
  SID[281]: S-1-22-2-621
  SID[282]: S-1-22-2-622
  SE_PRIV  0x0 0x0 0x0 0x0
[2009/04/17 19:45:33, 10] auth/token_util.c:debug_unix_user_token(548)
  UNIX token of user 500
  Primary group is 500 and contains 139 supplementary groups
[2009/04/17 19:45:34,  0] lib/util.c:smb_panic(1673)
  PANIC (pid 2568390): sys_setgroups failed

What happens at SID[143] is a complete mistery to me, as this is no
valid AD SID.
The enumeration stops when 139 additional SIDs have been added to the
list (SID[143] to SID[282]).
Now, since there are 139 supplementary groups and the OS only supports
up to 128 additional groups, sys_setgroups fails and dumps core.
I can only assume that smbd is creating additional UNIX groups for all
retrieved SIDs, so that SID[143] to SID[282] is a UNIX group enumeration
of SID[0] to SID[142], leaving out a few ones)

Can someone please explain to me what is happening here and why this
works well in the 3.0 series? What has changed?

Thanks

Miguel

****
This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights.
If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited.
Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient.
This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
****

Reply | Threaded
Open this post in threaded view
|

Re: sys_setgroups : migration issues from 3.0 series to 3.2/3.3 series

Volker Lendecke
On Fri, Apr 17, 2009 at 08:22:01PM +0200, [hidden email] wrote:
> Can someone please explain to me what is happening here and why this
> works well in the 3.0 series? What has changed?

We added that panic call because there has been a lot of
confusion due to groups being ignored. You should
reconfigure your Unix to allow sufficient groups for
sys_setgroups.

Volker

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: sys_setgroups : migration issues from 3.0 series to 3.2/3.3 series

miguel.sanders
Afaik that's a hard limit defined by the constant NGROUPS_MAX, which is
128 for my OS.
Does this mean I have to stick with the 3.0 series, even though the OS
didn't change this value in 10 years?

Thnx

-----Oorspronkelijk bericht-----
Van: Volker Lendecke [mailto:[hidden email]]
Verzonden: zaterdag 18 april 2009 10:48
Aan: SANDERS Miguel
CC: [hidden email]
Onderwerp: Re: sys_setgroups : migration issues from 3.0 series to
3.2/3.3 series

On Fri, Apr 17, 2009 at 08:22:01PM +0200,
[hidden email] wrote:
> Can someone please explain to me what is happening here and why this
> works well in the 3.0 series? What has changed?

We added that panic call because there has been a lot of confusion due
to groups being ignored. You should reconfigure your Unix to allow
sufficient groups for sys_setgroups.

Volker

****
This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights.
If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited.
Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient.
This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
****

Reply | Threaded
Open this post in threaded view
|

Re: sys_setgroups : migration issues from 3.0 series to 3.2/3.3 series

Volker Lendecke
On Sat, Apr 18, 2009 at 11:45:30AM +0200, [hidden email] wrote:
> Afaik that's a hard limit defined by the constant NGROUPS_MAX, which is
> 128 for my OS.
> Does this mean I have to stick with the 3.0 series, even though the OS
> didn't change this value in 10 years?

Well, you could comment out the call to smb_panic in
source/smbd/sec_ctx.c line 260 and recompile Samba. But then
you will probably (as in 3.0) see that some users can't
access files they should be able to access, because the OS
can not handle all the groups the user is member of.

Volker

P.S: I haven't tested that commenting out...

attachment0 (196 bytes) Download Attachment