Become_

[Douglas VanLeuven]

>From the logs:
[1999/06/15 14:54:08, 0] smbd/uid.c:become_root(370)
  ERROR: become root depth is non zero
[1999/06/15 14:54:08, 0] smbd/uid.c:unbecome_root(392)
  ERROR: unbecome root depth is 0

This has been nagging at me for some weeks.
So I added some DEBUG statements to dump the uids involved.

[1999/06/15 14:54:08, 0] smbd/uid.c:become_root(372)
  TRACE: become_root, current_user.uid=99
        [1999/06/15 14:54:08, 0] smbd/uid.c:become_root(372)
          TRACE: become_root, current_user.uid=0
        [1999/06/15 14:54:08, 0] smbd/uid.c:become_root(370)
          ERROR: become root depth is non zero
        [1999/06/15 14:54:08, 0] smbd/uid.c:unbecome_root(395)
          TRACE: unbecome root, current uid=0, old uid=0
[1999/06/15 14:54:08, 0] smbd/uid.c:unbecome_root(395)
  TRACE: unbecome root, current uid=0, old uid=0
[1999/06/15 14:54:08, 0] smbd/uid.c:unbecome_root(392)
  ERROR: unbecome root depth is 0

I realize it's just a nested become/unbecome pair that starts as user
nobody.
The problem is the 2nd call to become_root saves root information
in the static variable current_user_saved and the last (2nd)
unbecome_root
restores root info when it should be nobody.
I don't have the depth of understanding to ponder the security
implications of this.  So instead I patched it to avoid saving/restoring

the current_user unless in the first level call.

Anyone have a better idea?

Doug VanLeuven  : 707-545-6933 (voice) 707-545-6945 (fax)
Programmer/Analyst, SCWA  doug at scwa.ca.gov
Cheif Engineer, USMM  roamdad at ibm.net