2017-01-03 0:56 GMT+01:00 Stéphane Pgt <ps67....@outlook.com>:
>
> Hi Mathieu,

Hi,

>
> Thank you for pointing me to these bugs that I hadn't found during my 
> previous searches.
>
> From what I've understood, the changes introduced in response to upstream bug 
> 12155 are likely to be related with the issue.
>
>
> Indeed, the configuration with which I was able to reproduce the bug contains 
> those lines:
>
>     idmap uid = 10000-20000
>
>     idmap gid = 10000-20000
>
>
> But the UID and GID returned by getent for the domain accounts are all 
> greater than 100000:
>
> administrator:*:100500:100513:Administrator:/data/administrator:/bin/false
> testusr:*:101103:100513:testusr:/data/testusr:/bin/false
> krbtgt:*:100502:100513:krbtgt:/data/krbtgt:/bin/false
> guest:*:100501:100514:Guest:/data/guest:/bin/false
>
>
> Therefore, it may cause the computed UID value to fail the boundary check 
> that was introduced in the _wbint_Sids2UnixIDs function.
>
>
> What I don't explain is that the mapping of a domain account to a local UID 
> seems to works correctly (which is what _wbint_Sids2UnixIDs do), it is the 
> reverse operation that fails.

Maybe the boundary check is not done the other way.

>
> I've upgraded the lab to 4.5.2+dfsg-2 that has been released to testing 
> since, and I've noticed a very different behavior: the mapped UID and GID now 
> falls within the range defined by the idmap uid and idmap gid directives. It 
> seems that some change introduced in 4.5.2+dfsg-2 has solved this problem:

4.5.2+dfsg-1 and 4.5.2+dfsg-2 don't have any difference here. but
maybe you need to run "net cache flush"?

>
> root@v-smb-fs:~# getent passwd
>
> administrator:*:10000:10004:Administrator:/data/administrator:/bin/false
> testusr:*:10001:10004:testusr:/data/testusr:/bin/false
> krbtgt:*:10002:10004:krbtgt:/data/krbtgt:/bin/false
> guest:*:10003:10005:Guest:/data/guest:/bin/false
>
> root@v-smb-fs:~# wbinfo --user-info=testusr
> testusr:*:10001:10004:testusr:/data/testusr:/bin/false
>
> root@v-smb-fs:~# wbinfo --uid-info=10001
> testusr:*:10001:10004:testusr:/data/testusr:/bin/false
>
> Thank you for your help,

Please test again after a flush (and maybe removing winbind cache).

We need to put something in Debian NEWS file about this behavior
change for stretch. Andrew or Jelmer, do you have time to prepare the
wordings?

Regards

-- 
Mathieu

Reply via email to