Deleting and re-adding a domain user on a Samba PDC from windows results in
the 'add user script' not being called upon re-adding. I've traced this as far
as the pwnam_cache used in function getpwnam_alloc in file lib/util_pw.c. The
reason is that deleting the user doesn't remove it from the pwnam_cache. When
re-adding the same user immediately after, it is found in the cache and this
leads up to the 'add user script' not being called. The reason why this happens
on windows (not when using the net utility on linux) is that windows doesn't
close the RPC connection to the PDC after every command thus keeping the daemon
(including pwnam_cache) alive.
Use a basic Samba PDC, passdb_backend = tdbsam, no winbind. Both add and delete
user scripts configured.
Join a windows box and from there add, delete and re-add the same domain user
in quick succession. It doesn't matter if you use the command line or the
NT4-gui. The result is that the user doesn't exist in /etc/passwd after this
sequence. Note: The first add is just to create a user to start with. Deleting
and re-adding is sufficient.
If you consider this scenario rare in general: It was almost the first thing
that happened when we started testing user administration from windows on a
Samba PDC... Samba doesn't know or care whether the delete user script does
anything but it should remove the user from the pwnam_cache just to be safe.
That's probably mine -- I'll look at that tomorrow. Thanks for reporting!
Created attachment 1006 [details]
Patch committed with revision 5647
I've committed the attached patch. Closing bug, please re-open if this does not
works for me with the attached patch
from looking at the diff, I believe it should work. No time yet for testing.
I've noticed that in rpc_server/srv_samr_nt.c function _samr_create_user
there is an earlier explicit call pw = Get_Pwnam(account); The result
of this call determines whether to run the add user script. Preferably
flush_pwnam_cache(); before this call?
> I've noticed that in rpc_server/srv_samr_nt.c function _samr_create_user
> there is an earlier explicit call pw = Get_Pwnam(account); The result
> of this call determines whether to run the add user script. Preferably
> flush_pwnam_cache(); before this call?
Yes, I've considered that. But then I decided against it and instead tried to
fix all the places where we call scripts to modify a getpwnam output. To me this
seemed to be a better fix, as there might be other places lurking that depend on
getpwnam being current. This however does not fix the case where an admin
deletes a user below us, but we can't have both anyway. stat()'ing /etc/passwd
might be possible, but there is no general sequence number you could retrieve
from arbitrary nss backends.
Jerry, what do you think?
I've hacked the patch into 3.0.11 and it works for me. Will this make
it to 3.0.12?
(In reply to comment #6)
> I've hacked the patch into 3.0.11 and it works for me. Will this make
> it to 3.0.12?
volker, the fix sounds correct to me. Thanks.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.