Running gentoo hardened, kernel 2.6.34-r1, gcc 4.3.4 p1.1, pie-10.1.5, CFLAGS="-O2 -march=native -pipe", CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" Running a win2k8r2 ads pdc, set up samba with: passdb backend = tdbsam idmap config DOMAIN : backend = ad idmap config DOMAIN : readonly = yes idmap config DOMAIN : schema_mode = rfc2307 idmap config DOMAIN : range = 10000-20000 idmap uid = 10000-20000 idmap gid = 10000-20000 winbind nss info = rfc2307 winbind enum users = yes winbind enum groups = yes the pam plugin works, wbinfo works, getent, id, whoami all fail. stracing them and checking winbindd -i -d10 and comparing to working variants shows that usually getnet etc should open the privileged pipe to read the information. For some reason (this is where my debugging came to a halt) the nss plugin opens only the /tmp/.winbindd/pipe and does not request access to the privileged pipe. This situation did not change when I commented the above part out of smb.conf to fall back to idmp config backend = tdb.
I've just gone back to 3.4.8, and getent passwd works right away, connecting, and getting access to the privileged pipe.
getent passwd should not access the privileged pipe. It must be executable as non-privileged user. Only a few operations are restricted to the privileged pipe. Can you please post the strace of a failing getent passwd command together with the debug level 10 logs of winbind? Thanks, Volker
(In reply to comment #2) > getent passwd should not access the privileged pipe. It must be executable as > non-privileged user. Only a few operations are restricted to the privileged > pipe. Apparently, with 3.4.8, I am only getting winbind results into getent passwd, when running as root. As a user it tries to open the privileged pipe but fails due to lack of access rights. As root it will access the privileged pipe. So possibly the root issue is that the public pipe does not work - are there any straightforward configuration setting problems that could lead to the public pipe not preparing this data even though it is available via the privileged pipe? > > Can you please post the strace of a failing getent passwd command together with > the debug level 10 logs of winbind? I'll see if I can get a test environment running, I don't have a spare box on hand right now, I'll see if I can set up a VM. I distinctly remember from debugging with josh that his working 3.5 winbind was logging privileged pipe accesses (though possibly not in the strace), while these were absent on my version.
(In reply to comment #3) > (In reply to comment #2) > > getent passwd should not access the privileged pipe. It must be executable as > > non-privileged user. Only a few operations are restricted to the privileged > > pipe. > > Apparently, with 3.4.8, I am only getting winbind results into getent passwd, > when running as root. As a user it tries to open the privileged pipe but fails > due to lack of access rights. As root it will access the privileged pipe. > Right, this situation arose due to an issue with gentoo's broken ebuild. Now after fixing the install, I got the expected behaviour (attempted access to the privileged pipe, but fail and still the correct results via /tmp/.winbind/pipe). That means at the time the idmap .so's were those leftover from my previous 3.5.4 install (where the ebuild has been fixed to include the shared modules). Also, unless the nss plugin has changed in some way, getent should still attempt to open the privileged pipe, which it did not.
Sorry, I don't understand. Does it work now, or does it not work? Why do you require libnss_winbind to always connect to the privileged pipe? Volker
(In reply to comment #5) > Sorry, I don't understand. Does it work now, or does it not work? Why do you > require libnss_winbind to always connect to the privileged pipe? > > Volker > I've downgraded back to 3.4.8, which I've now got in a working state. This now works in the way you've described, ie. trying to connect to both pipes, but getting the correct info to getent from the public pipe. Previously, I had a messed up installation with the modules that came with the 3.5.4 installation being used by 3.4.8. This was where I got strange behaviour (results only from the privileged pipe, none from the public). Before that, I was running 3.5.4, where I would see no access attempts to the priv pipe, and got no results from the open pipe either. What I was remarking upon is the difference in requests. With 3.4.8 getent/nss_wb -always- also sends off a request to the priv pipe, even if it can't access it. This is completely missing with 3.5.4. Additionally the winbind logs I saw from a working 3.5 indicated that indeed requests to the priv pipe are normally created upon an incoming getent query (possibly only when run as root). This discrepancy in the logs is the only clue I have so far - hence my suspicion that it is in some way related to my issue. Again: I don't require privileged access. But where previously (3.4.8) there were access attempts, now (3.5.4) there are none, coinciding with the /tmp/ pipe not serving any data.
You had also spoken about a messed up install. I bet that the missing info on the public pipe was just due to a versioning issue of libnss_winbind with winbindd. Closing this as "WORKSFORME", as it does so.
(In reply to comment #7) > You had also spoken about a messed up install. I bet that the missing info on > the public pipe was just due to a versioning issue of libnss_winbind with > winbindd. The messed up install (missing --with-shared-modules in the ebuild) was for 3.4.8. The previously installed 3.5.4 had a working (bug fixed since 3.5.3) ebuild and should not have been impacted by those issues. I'm building a test system right now, so hopefully I'll have more info in a few days. My issues with 3.4.8 after I uninstalled 3.5.4 were only due to the 3.5.4 modules being installed. So that I'm pretty positive that my issues with 3.5.4 were NOT version-related. > Closing this as "WORKSFORME", as it does so. > I'll see about reopening once I determine whether it's possible to reproduce the issue on my test system.
(In reply to comment #7) > You had also spoken about a messed up install. I bet that the missing info on > the public pipe was just due to a versioning issue of libnss_winbind with > winbindd. > > Closing this as "WORKSFORME", as it does so. > Okay, finally got my testing VM up. First: things seem to work somewhat. I now get the expected log message: [2010/08/12 00:53:35.953091, 10] winbindd/winbindd.c:620(process_request) process_request: request fn WINBINDD_PRIV_PIPE_DIR Additionally "id" now delivers the correct information. Still, no winbind users in getent passwd. Again, strace shows the privileged pipe being accessed. At least now I can be sure it's not a compilation/configuration issue, as those were 1:1 on both boxes. Could have been a messed up install as you suspected, if I feel adventurous I'll give it another try on my "live" machine. For now though, the other issue remains. wb logs say this: (slightly abridged at the beginning) [2010/08/12 00:53:35.955143, 10] winbindd/winbindd.c:716(winbind_client_response_written) winbind_client_response_written[4081:WINBINDD_PRIV_PIPE_DIR]: deliverd response to client [2010/08/12 00:53:35.957785, 10] winbindd/winbindd.c:593(process_request) process_request: Handling async request 4081:SETPWENT [2010/08/12 00:53:35.958493, 10] winbindd/winbindd.c:655(wb_request_done) wb_request_done[4081:SETPWENT]: NT_STATUS_OK [2010/08/12 00:53:35.963331, 10] winbindd/winbindd.c:716(winbind_client_response_written) winbind_client_response_written[4081:SETPWENT]: deliverd response to client [2010/08/12 00:53:35.964381, 10] winbindd/winbindd.c:593(process_request) process_request: Handling async request 4081:GETPWENT [2010/08/12 00:53:35.964984, 3] winbindd/winbindd_getpwent.c:50(winbindd_getpwent_send) [ 4081]: getpwent [2010/08/12 00:53:35.966956, 10] winbindd/winbindd_cache.c:418(wcache_fetch_seqnum) wcache_fetch_seqnum: BUILTIN not found [2010/08/12 00:53:35.967580, 10] winbindd/winbindd_cache.c:4709(wcache_store_ndr) could not fetch seqnum for domain BUILTIN [2010/08/12 00:53:35.968187, 10] winbindd/wb_query_user_list.c:73(wb_query_user_list_done) rpccli_wbint_QueryUserList returned 0 users [2010/08/12 00:53:35.968829, 10] winbindd/wb_query_user_list.c:73(wb_query_user_list_done) rpccli_wbint_QueryUserList returned 5 users [2010/08/12 00:53:35.969447, 10] lib/gencache.c:345(gencache_get_data_blob) Returning valid cache entry: key = IDMAP/SID2UID/S-1-5-21-419380538-495824011-1797842603-500, value = -1, timeout = Thu Aug 12 00:55:08 2010 [2010/08/12 00:53:35.971110, 10] winbindd/wb_sid2uid.c:54(wb_sid2uid_send) idmap_cache_find_sid2uid found -1 [2010/08/12 00:53:35.971851, 5] winbindd/winbindd_getpwent.c:133(winbindd_getpwent_recv) getpwent failed: NT_STATUS_NONE_MAPPED [2010/08/12 00:53:35.972482, 10] winbindd/winbindd.c:655(wb_request_done) wb_request_done[4081:GETPWENT]: NT_STATUS_NONE_MAPPED [2010/08/12 00:53:35.973561, 10] winbindd/winbindd.c:716(winbind_client_response_written) winbind_client_response_written[4081:GETPWENT]: deliverd response to client [2010/08/12 00:53:35.975283, 10] winbindd/winbindd.c:593(process_request) process_request: Handling async request 4081:ENDPWENT [2010/08/12 00:53:35.975974, 10] winbindd/winbindd.c:655(wb_request_done) wb_request_done[4081:ENDPWENT]: NT_STATUS_OK [2010/08/12 00:53:35.979316, 10] winbindd/winbindd.c:716(winbind_client_response_written) winbind_client_response_written[4081:ENDPWENT]: deliverd response to client [2010/08/12 00:53:35.981678, 6] winbindd/winbindd.c:816(winbind_client_request_read) closing socket 25, client exited [2010/08/12 00:58:24.632976, 10] lib/events.c:123(run_events) Running timed event "rescan_trusted_domains" 0x64c6040fe0 wbinfo works as expected, doing full user mapping, and as I said, id %domainuser also works fine. I emptied the cache completely before this, so the cache entry is freshly fetched only seconds ago. rfc2307.so as well as sfu/sfu20 modules exist and point to ad.so, which exists next to ldap and rid.so all with creation times at the time of the last samba install. Not sure if this issue is worth reopening this bug for, as basic features appear to work at first glance. Missing getent entries might make for a new bug. getent group is riddled with more "failed" messages in the winbind logs. Notable among them is again: [2010/08/12 01:10:33.649001, 10] winbindd/winbindd_cache.c:418(wcache_fetch_seqnum) wcache_fetch_seqnum: BUILTIN not found [2010/08/12 01:10:33.649789, 10] winbindd/winbindd_cache.c:4709(wcache_store_ndr) could not fetch seqnum for domain BUILTIN and [2010/08/12 01:10:39.718066, 5] winbindd/winbindd_getgrent.c:149(winbindd_getgrent_recv) getgrent failed: NT_STATUS_NONE_MAPPED also I've just seen thw following: [2010/08/12 01:12:49.648793, 10] lib/gencache.c:180(gencache_set_data_blob) Adding cache entry with key = IDMAP/SID2UID/S-1-5-21-419380538-495824011-1797842603-500 and timeout = Thu Jan 1 01:00:00 1970 (-1281568369 seconds in the past) during a getent passwd call (after previously returning an expired cache entry) Looks goofy to me... Unsure whether this is a separate issue or somehow linked so I'll leave that here. Hopefully you'll be able to cut through this information.
another obversation: getent passwd %domainuser is returning the correct passwd information. getent passwd | grep %domainuser returns nothing. In 3.4.8 on the other hand I get the domain user listed in getent passwd. Could there be a broken interface?