Re: 1.5.12

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

At 10:51 AM 10/8/2004 -0400, Jason Tishler wrote:
>On Wed, Oct 06, 2004 at 05:07:49PM -0400, Christopher Faylor wrote:
>> Anything else?
>
>Unfortunately, yes.  I've just begun to track down the following Cygwin
>problem:
>
>    If a user tries to connect to proftpd when not logged in to Windows,
>    then the proftpd login fails because chdir() to the user's home
>    directory fails.  If they are already logged in to Windows, then the
>    proftpd login succeeds.
>
>I believe the problem is due to a bunch of seteuid() and setegid() calls
>by proftpd to drop root privileges which prevents Cygwin from being able
>to read its mount table in the registry.
>
>So far, I have the following strace from a failure:
>
>  218 8207898 [main] 27.0 3212 seteuid32: uid: 1027 myself->gid: 513
>  191 8208089 [main] 27.0 3212 seteuid32: Found token -1
> 1623 8209712 [main] 27.0 3212 set_process_privilege: 0 =
set_process_privilege (SeCreateTokenPrivilege, 1)
> 4311 8214023 [main] 27.0 3212 set_process_privilege: 1 =
set_process_privilege (SeCreateTokenPrivilege, 0)
>  402 8214425 [main] 27.0 3212 create_token: 1548 = create_token ()
>  989 8215414 [main] 27.0 3212 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20041007-1/winsup/cygwin/sec_helper.cc:346
windows error 1008
>  112 8215526 [main] 27.0 3212 geterrno_from_win_error: windows error 1008
== errno 22
>   63 8215589 [main] 27.0 3212 geterrno_from_win_error: windows error 1008
== errno 22
>   85 8215674 [main] 27.0 3212 set_process_privilege: -1 =
set_process_privilege (SeRestorePrivilege, 1)
>  248 8215922 [main] 27.0 3212 open_shared: name
S-1-5-21-3757435101-2935130677-2106517767-1027, shared 0xA010000 (wanted
0xA010000), h 0x750
>   81 8216003 [main] 27.0 3212 user_shared_initialize: opening user shared
for 'S-1-5-21-3757435101-2935130677-2106517767-1027' at 0xA010000
>   78 8216081 [main] 27.0 3212 user_shared_initialize: user shared version 0
>   62 8216143 [main] 27.0 3212 user_shared_initialize: initializing user
shared
>  149 8216292 [main] 27.0 3212 reg_key::build_reg: failed to create key
SOFTWARE in the registry
>  123 8216415 [main] 27.0 3212 reg_key::build_reg: failed to create key
SOFTWARE in the registry
>  163 8216578 [main] 27.0 3212 reg_key::build_reg: failed to create key
SOFTWARE in the registry
>   74 8216652 [main] 27.0 3212 mount_info::read_mounts: RegEnumKeyEx
failed, error 6!
>  122 8216774 [main] 27.0 3212 reg_key::build_reg: failed to create key
SOFTWARE in the registry
>   69 8216843 [main] 27.0 3212 mount_info::read_mounts: RegEnumKeyEx
failed, error 6!

<snip>
>
>Unfortunately, I haven't been able to create a simple test case yet.  :,(

Try this, running as SYSTEM
main()
{
	setgroups(0, NULL);
	setgid( );
	setuid( );
	chdir( );
}

>Does anyone have any ideas?

8215674 [main] 27.0 3212 set_process_privilege: -1 = set_process_privilege
(SeRestorePrivilege, 1)

It's from enable_restore_privilege() in load_registry_hive(), called from
seteuid32. 
That is running while deimpersonated but possibly while issetuid is true (!!!)
In that case there is no thread token and an error is expected.
Revert the 2004-04-19 change.

There is no message about the load failing. That indicates that either 
get_registry_hive_path() failed, or that the load succeeded. The former is 
more likely, at least if the program has run more than once (the load
would have succeeded on the first trial, and there would be a message that
the profile is already loaded).
Add a debug_printf if get_registry_hive_path() fails.

Two of the four reg_key::build_reg failures are from trying to read the
User cygdrive and mounts. That makes sense if the user profile is absent,
or if the Cygnus entry was never created in the HKCU.
The other two are from trying to read the System cygdrive and mounts.
proftp and (by default) exim run without auxiliary groups. So the HKLM
may be unreadable, although it is readable while logged in under ssh
or at the console. Giving read access to Everyone fixes that.
To fix this without giving access to Everyone, we could try to reread the
system mounts while deimpersonated, if there was a failure.

The chdir fails because the mount table is empty.

Pierre