[Samba] uid handling changes (was:Re: Error with samba-tool when upgrading from 3 to 4 / NT_STATUS_IO_TIMEOUT)

[Jeremy Allison]

On Sun, Jul 01, 2012 at 01:59:13PM +1000, Andrew Bartlett wrote:
> > > ../source3/lib/pidfile.c:154(pidfile_create)
> > > Jun 29 14:11:10 samba4 smbd[2627]:   ERROR: can't open 
> > > /usr/local/samba/var/run/smbd-fileserver.conf.pid: Error was Le 
> > > fichier existe
> > It seems that this file is already existing can you retry without this 
> > file ?
> > > Jun 29 14:11:31 samba4 smbd[2647]: [2012/06/29 14:11:31.356436,  0] 
> > > ../source3/param/loadparm.c:6337(service_ok)
> > > Jun 29 14:11:31 samba4 smbd[2647]:   WARNING: No path in service IPC$ 
> > > - making it unavailable!
> > > Jun 29 14:11:31 samba4 smbd[2647]: [2012/06/29 14:11:31.372172, 0] 
> > > ../source3/smbd/server.c:1266(main)
> > > Jun 29 14:11:31 samba4 smbd[2647]:   standard input is not a socket, 
> > > assuming -D option
> > > Jun 29 14:11:33 samba4 smbd[2647]: [2012/06/29 14:11:33.223200, 0] 
> > > ../source3/printing/print_standard.c:68(std_pcap_cache_reload)
> > > Jun 29 14:11:33 samba4 smbd[2647]:   Unable to open printcap file 
> > > /etc/printcap for read!
> > > Jun 29 14:11:43 samba4 smbd[2662]: [2012/06/29 14:11:43.118319, 0] 
> > > ../source3/lib/util_sec.c:124(assert_gid)
> > > Jun 29 14:11:43 samba4 smbd[2662]:   Failed to set gid privileges to 
> > > (-1,3000004) now set to (0,50884) uid=(0,0)
> > Also it's worth investigating why the script thinks that the UID is -1, 
> > obviously it will fail a bit.
> > I can advise first to rebuild with symbols then dig a bit and understand 
> > why the UID is -1.
> 
> I think -1 in this case is 'no change', but what is a worry is that a
> large number of our users have reported hitting this after Jeremy's
> per-thread uid handling changes.

Yep, -1 is no change. What platform is this on ? If it's not Linux
then the per-thread changes should have zero effect on the code
paths.

If it is Linux, then the per-thread changes have the effect of
moving us from using the the setreuid() mechanism to the setresuid()
mechanism, which is what we originally used on Linux.

We haven't used the setresuid() mechanism as our default since
2008, so if this is a real problem then it's easy to change
the default mechanism back to the equivalent of the setreuid()
codepath instead. I moved us back to setresuid() in the changes
as if it works (which it really should on Linux) it's a much
cleaner and simpler mechanism.

If you can get me more details, I can send the original user
some extra debugs which should allow me to track down and
fix any issue.

Thanks !

Jeremy.