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

[Derek Price]

Conrad T. Pino wrote:

>Hi Derek,
>
>  
>
>>From: Derek Price
>>
>>I think renaming this file "sys_types.h", starting it with `#include
>>', then defining what else you need would be an easier
>>interface to maintain.
>>
>>
>
>Are you implying changing all #include  in CVS? I assume no.
>  
>

Well, it may be an option if necessary, similar things have been
proposed for GNULIB modules, but none has turned out to be necessary yet.

In this case I was thinking that the Windows config.h.in.footer could
#include "sys_types.h" and get the effect you are looking for.

>I intend the "windows-NT" version be used in all locations cited at the
>end of this message.
>
>My first try was your suggestion with the current name only to discover VC6
>reopens the "windows-NT" file because "windows-NT" is in the include path.
>  
>

Which is why I proposed renaming the Windows include to "sys_types.h". 
I also dislike polluting the windows-NT source directory space with a
directory structure mimicing a standard C89/POSIX include structure with
no differentiation from the other source files if you can avoid it.  If
you must, I might prefer moving your sys directory under a
windows-NT/include directory and making the other changes you needed to
to accomodate that, but I still prefer avoiding the sys directory
entirely in favor of the "sys_types.h" file.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

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

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

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> I think renaming this file "sys_types.h", starting it with `#include
> ', then defining what else you need would be an easier
> interface to maintain.

Are you implying changing all #include  in CVS? I assume no.

I intend the "windows-NT" version be used in all locations cited at the
end of this message.

My first try was your suggestion with the current name only to discover VC6
reopens the "windows-NT" file because "windows-NT" is in the include path.

Microsoft's implementation is so lame it's acquired the virtue of brevity.
I might change my approach after reviewing the .NET  file.

> Regards,

Ditto,

> Derek

File diff\diffrun.h:
24  #include 
File diff\system.h:
27  #include 
File lib\dev-ino.h:
4   # include 
File lib\getline.h:
27  # include 
File lib\getndelim2.h:
24  #include 
File lib\getnline.h:
23  #include 
File lib\openat.h:
24  #include 
File lib\regex.h:
24  #include 
File lib\system.h:
49  #include 
File lib\timespec.h:
24  # include 
File lib\wait.h:
15  #include   /* For pid_t. */
File windows-NT\ndir.h:
19  #include   /* ino_t definition */
File windows-NT\pwd.h:
19  #include 
File windows-NT\unistd.h:
30  #include 
File zlib\zconf.h:
282 #  include  /* for off_t */
File lib\cycle-check.c:
26  #include 
File lib\fseeko.c:
19  #include 
File lib\ftello.c:
19  #include 
File lib\ftruncate.c:
8   #include 
File lib\getcwd.c:
28  #include 
File lib\gettimeofday.c:
32  #include 
File lib\glob.c:
26  #include 
File lib\mkdir.c:
29  #include 
File lib\mktime.c:
36  #include   /* Some systems define `time_t' here.  
*/
File lib\nanosleep.c:
28  #include 
File lib\readlink.c:
23  #include 
File lib\rpmatch.c:
27  # include 
File lib\sighandle.c:
36  #include 
File lib\stat.c:
31  #include 
File lib\strftime.c:
38  #include   /* Some systems define `time_t' here.  
*/
File lib\sunos57-select.c:
39  #include 
File lib\tempname.c:
24  #include 
File lib\xreadlink.c:
31  #include 
File os2\popen.c:
11  #include
File os2\rcmd.c:
20  #include 
File os2\run.c:
23  #include 
File src\expand_path.c:
16  #include 
File windows-NT\ndir.c:
24  #include 
File windows-NT\rcmd.c:
26#include 
File zlib\minigzip.c:
29  #  include 
File zlib\contrib\minizip\minizip.c:
18  # include 
File zlib\contrib\puff\puff.c:
789 #include 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

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


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

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

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

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

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

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLXVLD1OTBfyMaQRAqR1AJ9b7K8yExwUCc0EIj4jUrersoSyJQCgsjec
sHEymcNNNjRzXscCVdl36pY=
=1rqH
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

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

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

>#ifdef _MSC_VER
>
>#pragma once
>
>/* Compatable with Visual C++ 6.0 - cl.exe 12.00 */
>#if _MSC_VER != 1200
>#pragma message ( "Please email Microsoft's " )
>#pragma message ( "file to <[EMAIL PROTECTED]>" )
>#endif /* _MSC_VER != 1200 */
>
>/***/
>/* Mimic what Micrsoft defines in their  */


I think renaming this file "sys_types.h", starting it with `#include
', then defining what else you need would be an easier
interface to maintain.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLbULD1OTBfyMaQRArmUAKD8v6H424DG0POXEl7sNAfC3GKWzwCdF4U7
Zzt7J1nnG24jYChR8DKE7Jg=
=3dJw
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs