Bug 2401 - add user script not called when deleting/re-adding user from windows
add user script not called when deleting/re-adding user from windows
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control
3.0.11
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-01 14:30 UTC by Dieter Stampfer
Modified: 2005-08-24 10:16 UTC (History)
0 users

See Also:


Attachments
Patch committed with revision 5647 (2.31 KB, patch)
2005-03-03 09:56 UTC, Volker Lendecke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dieter Stampfer 2005-03-01 14:30:48 UTC
Hi,

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.

To reproduce:

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.

Thanks, Dieter
Comment 1 Volker Lendecke 2005-03-01 14:46:22 UTC
That's probably mine -- I'll look at that tomorrow. Thanks for reporting!

Volker
Comment 2 Volker Lendecke 2005-03-03 09:56:13 UTC
Created attachment 1006 [details]
Patch committed with revision 5647

I've committed the attached patch. Closing bug, please re-open if this does not
fix it.

Volker
Comment 3 Volker Lendecke 2005-03-03 09:57:07 UTC
works for me with the attached patch
Comment 4 Dieter Stampfer 2005-03-03 12:02:15 UTC
Hi,

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?

Regards, Dieter
Comment 5 Volker Lendecke 2005-03-03 12:27:10 UTC
> 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?

Volker
Comment 6 Dieter Stampfer 2005-03-04 14:42:16 UTC
Hi,

I've hacked the patch into 3.0.11 and it works for me. Will this make
it to 3.0.12?

Regards, Dieter
Comment 7 Volker Lendecke 2005-03-04 16:42:07 UTC
(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?

Sure.

Volker
Comment 8 Gerald (Jerry) Carter 2005-03-07 10:00:31 UTC
volker, the fix sounds correct to me.  Thanks.
Comment 9 Gerald (Jerry) Carter 2005-08-24 10:16:41 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.