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

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> >Log:
> > * unistd.c, unistd.c: Add new "usleep" function using "my_usleep"
> > logic taken from "woe32.c" file.
> > * woe32.c, woe32.h: Add new (woe32_home_dir,woe32_shell) functions.
> > * woe32.c: Modify "woe32_nanosleep" to use "unistd.h" "usleep".
> 
> Glancing at lib/nanosleep.c, the usleep() implementation in
> windows-NT/unistd.c, and based on the fact that signal() and select()
> appear to be used elsewhere in windows-NT/*.c, it looks like
> lib/nanosleep.c would compile on Windows with the right config.h.in.in
> definitions.  Then the woe32_nanosleep and unistd.c usleep could be
> removed in favor of the rpl_nanosleep in lib/nanosleep.c.

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.

* I don't know how to verify the change is no worse than current.

* Even though CVS doesn't use "usleep" I'd like to keep it for now as the
  best candidate to implement the millisecond resolution Windows supports
  in case Microsoft's "select" implementatino is ill behaved.

* I haven't proven to myself the actual time out granularity of Microsoft's
  "select" implementation and some cases I've contemplated suggest another
  choice.

Let me share some things I've learned about Windows and process delays:

* Windows native API "Sleep" call is a real time programming joke.  It
  specifies millisecond resolution but always surrenders balance of the
  current time slice:
  http://msdn.microsoft.com/library/en-us/dllproc/base/sleep.asp
  On a busy system your process runs at the hardware timer tick rate
  which is the standard PC BIOS rate of 18+ ticks per second.

* 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.

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

Does the MKS Tool Kit "sh" implementation help any?

Is Windows 2000 "bash" combined with MKS Took Kit a better start?

> > * 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?

* 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.

Windows NT and kin implement environment variables in three layers:

1. System environment variabiles require Administrator privilege to
   modify and most users are workstation Administrators.  These are
   persisted in the system registry

2. User environment variables.  These are persisted in the user
   profile registry.

3. Process environment variables.

The process set is built from System and User values preferring the
User value in some cases or concatenating others like %PATH% placing
the User value before the System value.  The process is then free to
mangle with no restrictions.  Child processes inherent from parent
when spawned.

My suggestions are:

   - Remove "login_strings" support altogether
OR
   - Leave "USERNAME" since it subtracts nothing and adds a bit.

What does CVS do with "getlogin" value that raise security threats?

> Regards,

Ditto,

> Derek

Conrad