Re: CVS update: /ccvs/windows-NT/

[Derek Price]

Conrad T. Pino wrote:

>The timer code in "lib/nanosleep.c" looks very good but I'm uncomfortable
>making a commitment to making the change because:
>
>* I don't understand UNIX style signal behavior well.
>  
>

Basically, signals normally cause a process to exit unless a handler is
installed.

>* Millisecond resolution delays without surrendering the time slice are
>  possible by creating an unsignaled Event then waiting for that Event
>  with a time out value.  This feature requires hardware support in CPU
>  otherwise behavior reverts to the PC BIOS rate.
>
>I'll work up a test program to measure "select" time out granularity in
>the next few days.
>
>I'll support you to the best I can should you choose to make the change.
>  
>

This was just a suggestion as I thought it might simplify things.  You
can make the call.

I would argue that the signal handling is no argument since
windows-NT/run.c is making calls to signal, I would assume that the API
is likely similar to UNIX and whoever wrote lib/nanosleep.c knew what
they were doing until we discover problems.

Your timer granularity argument sounds reasonable, however.  If you need
to reimplement usleep anyhow, then you can't really compuile
lib/nanosleep.c on Windows without rewriting it anyhow.  I found this
thread where we discussed this previously:
<http://lists.gnu.org/archive/html/bug-cvs/2004-05/msg00161.html>.  Jim
Hyslop suggests that NTP (www.ntp.org) uses QueryPerformanceCounter()
and QueryPerformanceFrequency() to hack around the problem with about a
300ns granularity.

>Can you share some ideas on what I need to do to get "sanity.sh" to run
>on Windows 2000?
>  
>

I have had it up and running before using a version of CVS built with
cygwin (http://cygwin.com), using the bash and other tools from cygwin. 
Most of the hacks I made to get that to work should still be in sanity.sh.

IIRC, however, testing an executable built with MSVC is a different
story because it can sometimes use "\" and sometimes "/" as a file
separator.  No one has ever installed the machinery in sanity.sh to
handle that.  It might be possible to make a small change in
dotest_internal() that seds the program output and replaces all
backslashes with forward slashes before the text goes to expr for the
comparison.  That is where I think I would start trying to get this running.

>Does the MKS Tool Kit "sh" implementation help any?
>
>Is Windows 2000 "bash" combined with MKS Took Kit a better start?
>  
>

Like I said, I started with Cygwin and the Cygwin bash.  Don't know what
the differences are between MKS and Cygwin.  sanity.sh requires a
working /bin/sh and a few standards compatible tools: expr, id, tr, and
sed are the most sensitive tools, I believe.  If you are attached to MKS
but one of those tools is broken, you might get sanity.sh running by
building and installing the GNU versions there.  The TESTS file
describes where to get them.

>>>* filesubr.c: Modify "get_homedir" to use "woe32_home_dir".
>>>* pwd.c: Modify "getpwuid" to use "woe32_home_dir" & "woe32_shell".
>>>Append "USERNAME" to "login_strings" array.
>>>      
>>>
>>Again, unless USERNAME is a read-only env var, if there is a Windows API
>>for retrieving these sorts of values, it should probably be used in the
>>POSIX replacements in favor of writable environment variables.
>>    
>>
>
>I agree in principle but several things indicate this is a non-issue:
>
>* Microsoft's workstation security practices commonly grant the CVS user
>  root equivalent privilege on the executing platform.  Why infringe on
>  the user's right to destroy local resources since they're effectively
>  all owned by the workstation user?
>  
>

One more time:

   1. I think a POSIX-compliant getpwuid function, or as near as we can
      get on Windows, should not use environment variables if at all
      possible if you wish to implement it in such a way that it
      complies as closely as possible with the POSIX spec so that it may
      be shared with other projects.
   2. I think there is no harm in the CVS get_homedir function using env
      variables.  CVS does that on UNIX on exactly the principle you
      state.  If the user set it then we will presume they knew what
      they were doing and let system security measures take care of
      things if the user is asking us to do something we shouldn't.


>* The better security route indicates we should remove "login_strings"
>  altogether since the addition/removal of a single variable doesn't
>  close the security vulnerability.
>  
>

This is exactly what I was advocating.  To meet the POSIX specs, these
functions should try to obtain the login name securely.  The POSIX
argument stands regardless, but a get_homedir-like wrapper would be
wrong here for CVS as well.  This value is entered in the repository as
the author of a commit and I would rather know that the user had to have
a password for the userid being used.  At the least, it shouldn't be so
easy to forge the author of a commit by setting an env var.

Regards,

Derek