This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reorganizing internal_getlogin()


At 10:12 PM 6/12/2002 -0400, you wrote:
>Yes, and as I explained previously, I didn't really like what you did to
>spawn_guts or your additions to environ.cc.  

You never really explained why, except the style of the names!

Currently seteuid unsets USERNAME and USERDOMAIN, which will
cause them to be set again, and HOMEPATH and HOMEDRIVE to be changed.
LOGONSERVER should be changed (or verified) as well, even if it is 
already set. So the environment is traversed at least 7 times.

Those 7 passes (not to mention contacting logonsevers to get the 
info) are only useful if there is an exec(), and that's why 
spawn_guts is the logical place to do it. 

The way I did it was for efficiency, only 1 pass through the whole 
environment. There is also the issue of variables such as HOMESHARE,
which become invalid (not a problem if SYSTEM does the setuid, but..).
It would have been much easier to write a routine doing explicit 
setenv and unsetenv, called from spawn_guts. Perhaps this is a way out.
What I did was probably overkill.

The other important change I did was not to call internal_login at
all from seteuid, and to avoid calling LookupAccountSid() [another
logonserver lookup, really] . Calling internal_getlogin
is useless (except for setting the environment) and it has the 
additional cost of traversing passwd.

>If you don't set the child's uid here then where is it going to be set?

It's already set! (as is myself->gid and the rest).
BTW spawn_info->moreinfo->uid has a misleading name (probably for
historical reasons). It's currently used as flag (when set to
INVALID_UID) to indicate CreateProcessAsUser.

>The correct way to find out if the parent is a cygwin process is to
>check for ppid_handle.  If it is zero, then the parent was not a cygwin
>process.  I've already made this change to uinfo.cc.

I just checked (printed myself->procinfo in gdb), same problem as ppid. 
If Windows starts a Cygwin process and this process exec()s.' then the 
exec'ed process has ppid_handle==0 even though the parent is a cygwin
process.

Pierre

P.S.: here is the missing uinfo.cc patch. Sorry.

Attachment: uinfo.cc.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]