smbclient is opening /var/cache/samba/gencache.tdb with write permissions during name resolution. This works when running smbclient as root, but fails when running as a normal user. As a result, when I run smbclient I always get a cache miss during name lookup. I hope this is a bug, not a feature! I don't know enough about the interfaces that smbclient is using to know if this is a problem with it, or one of the libraries that it's using. A cursory looks at client.c made me think that smbclient didn't have any control over something so low-level as cache access, so I think this is in libsmbclient, or maybe lower? I'm using the standard Redhat 9 samba 3 beta 3 RPMS provided by samba.org.
The main reason I filed this bug was because smbclient wasn't resolving names for me at all when running as a user. I think that there are actually two separate issues - one being cache usage, and the other described below: It turns out that my "wins server" configuration line in /etc/samba/smb.conf had a typo in the first server IP address, but the second server IP address was OK. For some reason or another, when I ran smbclient as root, the first IP address timed out, and the second one was successfully tried and used to look up the name. When I run smbclient as a user, it didn't try to use the second IP address after trying the first one. So, by "luck" I've managed to run into a situation that probably looks a lot like a scenario where the primary WINS server is down. What appears to be happening is that because gencache can't be written to, the code in source/libsmb/namequery.c:resolve_wins() that checks to see if an IP is dead doesn't work, and it retries the dead IP address once again, then gives up without ever trying a name lookup on the second (valid) WINS IP address. I imagine that making it possible to mark an IP address dead from user space will fix the problem, since the same code works when run as a root user, but I don't quite see why, yet. I'll look at this some more, but any ideas would be appreciated.
>I hope this is a bug, not a feature! Sorry, it's a feature. It would be nice if non-root processes could update the netbios name cache but unfortunately that can lead to denial of service attacks or security breaches. The solution unfortunately is to not let user processes write to the cache. It should be OK to let non-root processes read the cache, but I don't think this is implemented. The multiple WINS server problem you describe sounds like a bug though. smbclient should definitely fail over to the second wins server if the first one fails. Would you be able to post some level 10 logs if you have them? (Reassigning to smbclient as it's not a libsmbclient bug)
Created attachment 60 [details] log of 'smbclient -d 10 -L dummy' Yeah - I can see the security problem. Is there no appropriate IPC mechanism to have a user mode client query the nmbd daemon, which ought to be able to safely update the cache? Anyway, back to the problem at hand - I think I see what's causing the problem. Poking through the code some more, it looks like resolve_wins() relies on wins_srv_ip_tag() generating different IP addresses for each iteration of the inner loop in resolve_wins(). It would work if gencache had the IP address marked as dead, but since it doesn't, it will always return the first entry in the set of wins servers for the tag. I would think that unless libsmbclient isn't supposed to support user programs at all, this has to be a bug in libsmbclient. If libsmbclient can't write to the root-owned cache, all I could think to do would be to make a new instance of gencache, private to the user, and use that. That would seem to be the thing to do in the case where nmbd isn't running as well, which is probably common on machines that aren't actually running samba as a server. If nmbd were running, and could be used to do the name lookup, that would work as well, I guess. Picking a solution is well beyond my familiarity with the samba design, though. P.S. The traces aren't great, I'm afraid, but I'll attach them anyway. I'm pretty sure you won't need them if I was able to explain the rest of this properly.
Created attachment 357 [details] Fixes root problem - gives each user own lock and pid dirs This patch changes samba to pay attention to the uid when determining where to put pid and lock files. Root continues to honor variables set in smb.conf for the PID and LOCK directories. Other users will use directories under /tmp/<username>-samba. I'm open to suggestions for a better directory than /tmp. The net effect is that each user ends up with his own cache. Preliminary testing with smbclient works just fine. Permission on the end up being "drwxr-xr-x", which is the same as the root-owned cache. I'm presuming that passwords aren't being cached in there. This solves the root problem. Is it acceptable?
Created attachment 358 [details] Runs after smb.conf is parsed to prevent it from overriding per-user value smb.conf can override the defaults with the 'pid directory' and 'lock directory' keys. I moved the per-user setup code to a location that would be applied after smb.conf is parsed. The original location would have been overriden by smb.conf, which is not desired (smb.conf setting should be for root user only, since that's the only user with write access in a typical installation).
marking as resolve later. Not going to fix this right now.
originally reported against 3.0.0beta3. CLeaning out non-production release versions.
database cleanup