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
>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
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
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
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
marking as resolve later. Not going to fix this right now.
originally reported against 3.0.0beta3. CLeaning out
non-production release versions.