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() patch is in


At 10:00 PM 6/17/2002 -0400, Christopher Faylor wrote:
>>>I don't understand what you mean by "env" and "/bin/env".  The type command
>>>in bash tells me that env == /bin/env.
>I'm sorry but I'm still not getting it.  "type bin" returns "command not
>found" on my system.  AFAIK, I only have one "env" command and it is
>"/usr/bin/env".

Dyslexia, I meant "type env" returns /usr/bin/env, which is on a cygexec
drive. So your optimization kicks in when I type "env".
/bin/env invokes exactly the same program, but somehow it's not recognized
as being on a cygexec drive and your optimization does not kick in.
  
>>>For the same reason as we are meticulously saving all of these other
>>>environment variables, I guess.  Somebody could use them.
>>
>>Silly me.  But shouldn't USERPROFILE also be saved?

I see where USERPROFILE is evaluated from get_registry_hive_path()
when it is copied back to the environmnet. Similarly HOMEPATH
*can* be obtained from NetUserGetInfo ().
However HOMEPATH, but apparently not USERPROFILE, is initialized 
from the env on startup.
 
>I did add some code to only perform the expensive calculations when cygwin
>was setuid'ed but I think that won't work correctly when a cygwin child of
>an setuid'ed program tries to start a windows-only program and endeavors
>to recalculate things.  If I understand the problem correctly it sounds
>like the child will become confused due to the fact that it was created
>by CreateProcessAsUser.  However, hasn't this always been how it worked?

You understand the problem perfectly.
The old way out was to call LookupAccountSid(childsid) BEFORE calling
CreateProcessAsUser, and to pass the USERNAME and USERDOMAIN in the
environment, to be read by internal_getlogin. 

Your new way (passing the info in "user") is much more efficient.
However "user" needs to be updated before calling CreateProcessAsUser.
That's what the patch I sent on Sat is doing.

There is no need to copy the "user" fields to USERNAME and USERDOMAIN,
except possibly when calling a Windows program. They are, AFAWK, the only
practical means for the program to find out its user name! (but 
there are ways to find the domain).

Pierre


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