Bug 931 - 'virtual' winbind UIDs changing at boot with an other kernelrelease
Summary: 'virtual' winbind UIDs changing at boot with an other kernelrelease
Alias: None
Product: Samba 2.2
Classification: Unclassified
Component: winbind (show other bugs)
Version: 2.2.8a
Hardware: All Linux
: P3 normal
Target Milestone: ---
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Reported: 2003-12-30 04:49 UTC by Volker Hayd
Modified: 2005-11-14 09:27 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Volker Hayd 2003-12-30 04:49:08 UTC

we've a problem with shifting UIDs in 'getent passwd' after booting to another

our environment is :

Redhat 7.3 with kernel-smp-2.4.20-24.7 and kernel-smp-2.4.20-27.7

configured to import about 1400 Windows UserIDs and groups from an W2K Domain
which is running in Domain compatibility mode (NT-Servers are available too).

The UIDs change only on a machine if we are booting the other kernel. If we boot
the other (old) kernel again, the UIDs are changing back to the old values. The
new values that are beeing determined at the first time this kernel is booted
seems to be ordered by connection appearance. My account i.e. changed from 10478
to 10000 an I think I was the first user who has connected to the SaMBa server
via 'net view' from an W2K Client.

Isn't this a security probleme ?

Please let us know, if you need further information.

The phenomen looks like this :

USERID:UID NEW:SID NEW:COMMENT NEW          with kernel-smp-2.4.20-27.7
USERID:UID OLD:SID OLD:COMMENT OLD          with kernel-smp-2.4.20-24.7

user1:10000:S-1-5-21-992154867-1959481406-1541874228-6523 1:Comment
user1:10002:S-1-5-21-992154867-1959481406-1541874228-6523 1:Comment

user2:10001:S-1-5-21-992154867-1959481406-1541874228-6370 1:Comment 
user2:10003:S-1-5-21-992154867-1959481406-1541874228-6370 1:Comment

user3:10002:S-1-5-21-992154867-1959481406-1541874228-4101 1:Comment
user3:10004:S-1-5-21-992154867-1959481406-1541874228-4101 1:Comment

user4:10003:S-1-5-21-992154867-1959481406-1541874228-5900 1:Comment
user4:10005:S-1-5-21-992154867-1959481406-1541874228-5900 1:Comment

user5:10004:S-1-5-21-992154867-1959481406-1541874228-5425 1:Comment
user5:10006:S-1-5-21-992154867-1959481406-1541874228-5425 1:Comment

winbind relevant keywords in /etc/samba/smb.conf :

   password server      = PDC BDC
   security             = domain
   winbind separator    = +
   winbind uid          = 10000-20000
   winbind gid          = 10000-20000
   winbind cache time   = 15
   winbind enum users   = yes
   winbind enum groups  = yes
   template homedir     = /home/%D/%U
   template shell       = /bin/false
Comment 1 Volker Lendecke 2004-01-04 04:58:09 UTC
What does a debug level 10 log.winbindd with the failing kernel say? 
It sounds like a corrupt or otherwise not useable winbindd_idmap.tdb.

Do you have reiserfs running? I've seen problems with .tdb-files on reiserfs
Comment 2 Volker Hayd 2004-01-05 01:47:51 UTC
/var is a separate filesystem in our configurations and is formatted as an ext3,
is sized properly and is being mounted before winbind starts (S91winbind in
runlevel 3).

the permission of the file is

-rw-------    1 root     root       253952 Jan  5 10:15 winbindd_idmap.tdb

I'll send you the debuglevel 10 output of log.winbindd to vl@samba.org. 

sorry, for your information : it fails with any kernel but the changes appear
only when booting it the first time. A second or third boot of the same kernel
doesn't fail.
Comment 3 Volker Hayd 2004-01-07 04:13:43 UTC
I`ve found the putative bug.

It is not a bug. This behavior is caused by RedHat initscripts. They are
cleaning all files in the folder /var/lock/samba when you are booting to an
other kernelrelease. Then winbindd creates a new database with certainly new UIDs.

solution was to insert a line 'lock dir = /somewhere/else/than/var/lock' in the
glogal section of smb.conf

Thank you for helping to find out the problem
Comment 4 Volker Lendecke 2004-01-07 04:38:28 UTC
Fixed as verified by Volker Hayd.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:27:33 UTC
database cleanup