Re: uid/gid issues on 2.6.26-rc2

[Helge Deller <deller@gmx.de>]

John David Anglin wrote:
> On Sun, 18 May 2008, Thibaut VARENE wrote:
> 
>> Then, checking auth.log, I spotted a few very surprising things:
>>
>> May 18 09:15:04 mkhppa3 sshd[1265]: Invalid user varenet from 147.215.7.200
>> May 18 09:15:04 mkhppa3 sshd[1265]: Failed none for invalid user
>> varenet from 147.215.7.200 port 58220 ssh2
> 
> I have seen this today testing 2.6.28 (32-bit UP).  The problem is also
> present in postfix:
> 
> dave@hiauly6:/var/log$ less mail.err
> Dec 27 12:45:41 hiauly6 postfix/sendmail[16726]: fatal: file /etc/postfix/main.cf: parameter mail_owner: unknown user name value: postfix
> 
> The only place this can occur is here:
> 
> static void check_mail_owner(void)
> {
>     struct passwd *pwd;
> 
>     if ((pwd = getpwnam(var_mail_owner)) == 0)
> 	msg_fatal("file %s/%s: parameter %s: unknown user name value: %s",
> 		  var_config_dir, MAIN_CONF_FILE,
> 		  VAR_MAIL_OWNER, var_mail_owner);
> 
> So, the problem is with getpwnam.  I don't see this with 2.6.22.19, so
> the problem is likely a syscall issue.  These seem to be the syscalls
> that directly relate to the getpwnam call:
> 
> open("/lib/libnss_files.so.2", O_RDONLY) = 3
> read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0$\f\0\0\0004\0"..., 512) = 512
> fstat64(3, {st_mode=0, st_size=0, ...}) = 0
> mmap(NULL, 52324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40b92000
> mmap(0x40b9e000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x40b9e000
> close(3)                                = 0
> munmap(0x4051b000, 30889)               = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
> _llseek(3, 0, [0], SEEK_CUR)            = 0
> fstat64(3, {st_mode=0, st_size=0, ...}) = 0
> mmap2(NULL, 1557, PROT_READ, MAP_SHARED, 3, 0) = 0x407ae000
> _llseek(3, 1557, [1557], SEEK_SET)      = 0
> munmap(0x407ae000, 1557)                = 0
> close(3)                                = 0
> exit_group(0)                           = ?
> 
> The failure appears random.  I think the problem occurs shortly after
> forking.  It doesn't seem to be present in the 64-bit SMP 2.6.28 test
> kernel that I'm testing.

I think your assumption that it is related to fork might be correct.
I don't see the uid/gid issues, but instead very often when I ssh the first
time into the 32bit kernel of a parisc box this message:
[deller@halden deller]$ ssh c3000 -Xl root
ssh_exchange_identification: Connection closed by remote host

But the second try suddenly works:
[deller@halden deller]$ ssh c3000 -Xl root
Password:

It appears random as well, and since I think sshd forks itself, it could
be that we have some fork()-problem...

Helge