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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs