[PATCH] One liner to allow i786 in cygwin

This patch allows the Cygwin DLL to be configured and compiled for
--{host,build,target}=i786-pc-cygwin.

After applying a pending patch to the toplevel config.sub as well as the
hand changing the questionable old copies of config.sub that need to be
in the mingw and w32api directories,  I have configured, compiled and
installed the DLL for --{host,build,target}=pentium4-pc-cygwin.  A make
check showed zero unexpected failures and one unexpected pass:
ltp/gethostid01.c.

Similar patches have already been installed for the toplevel, binutils,
libiberty, and newlib.

I also have a simple autoconf/automake patch pending which corrects the
need for the (IMO bogus) mingw/w32api config.{sub,guess}.  Should I also
post that patch here for inclusion in the Cygwin versions of
autoconf/automake.

Kelley Cook

2003-06-03  Kelley Cook  <kelleycook <at> wideopenwest.com>

	* configure.in: Allow i786 variant.
	* configure: Regenerate.

--- cygwin/configure.in.orig	2003-06-03 10:43:30.000000000 -0400
+++ cygwin/configure.in	2003-06-03 10:27:26.000000000 -0400
 <at>  <at>  -205,7 +205,7  <at>  <at> 

stat weird feature

Here is the patch discussed today on the developers' list.
I have also moved a comment that had drifted out of its 
natural spot.

Pierre

2003-06-04  Pierre Humblet  <pierre.humblet <at> ieee.org>

	* fhandler_disk_file.cc (fhandler_disk_file::fstat): Mark the pc
	as non-executable if the file cannot be opened for read. Retry query 
	open only if errno is EACCES. Never change the mode, even if it is 000 
	when query open() fails. 

Index: fhandler_disk_file.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_disk_file.cc,v
retrieving revision 1.54
diff -u -p -r1.54 fhandler_disk_file.cc
--- fhandler_disk_file.cc	1 Jun 2003 19:37:13 -0000	1.54
+++ fhandler_disk_file.cc	4 Jun 2003 00:54:25 -0000
 <at>  <at>  -137,8 +137,6  <at>  <at>  fhandler_disk_file::fstat (struct __stat
 {
   int res = -1;
   int oret;
-  __uid32_t uid;
-  __gid32_t gid;
   int open_flags = O_RDONLY | O_BINARY | O_DIROPEN;
   bool query_open_already;

Re: stat weird feature

On Tue, Jun 03, 2003 at 09:22:15PM -0400, Pierre A. Humblet wrote:
>Here is the patch discussed today on the developers' list.
>I have also moved a comment that had drifted out of its 
>natural spot.
>
>Pierre
>
>2003-06-04  Pierre Humblet  <pierre.humblet <at> ieee.org>
>
>	* fhandler_disk_file.cc (fhandler_disk_file::fstat): Mark the pc
>	as non-executable if the file cannot be opened for read. Retry query 
>	open only if errno is EACCES. Never change the mode, even if it is 000 
>	when query open() fails. 

Looks good.  Please check in.

cgf

Assignment received for Micha Nelissen

We've received the assignment for Micha Nelissen.  That means
that any patches are now live, so review away.

cgf

[PATCH] Return correct error code on subsequent nonblocking connect

Corinna,

after our long discussion about interruptible connects i did some checks
with nonblocking connects.

While the opengroup spec is quite clear (and this time Linux behaves the
same) that the first connect should return EINPROGRESS and following
connects EALREADY cygwin returns always EINPROGRESS. Attached patch fix
this to return EALREADY on the second and all following connects. As a
side effect this will change interrupted blocking connects to return
EALREADY too (and not block again) as we have discussed before.
I think that this more opengroup alike.

Thomas

2003-06-06  Thomas Pfaff  <tpfaff <at> gmx.net>

	* fhandler_socket.cc (fhandler_socket::connect): Change error
	handling for nonblocking connects to return EALREADY when
	connect is called more than once for the same socket.

--- fhandler_socket.cc.org	2003-06-06 10:34:29.000000000 +0200
+++ fhandler_socket.cc	2003-06-06 10:45:00.000000000 +0200
 <at>  <at>  -502,6 +502,7  <at>  <at>  fhandler_socket::connect (const struct s
   BOOL in_progress = FALSE;
   sockaddr_in sin;
   int secret [4];
+  DWORD err;

Re: [PATCH] Return correct error code on subsequent nonblocking connect

On Fri, Jun 06, 2003 at 11:11:00AM +0200, Thomas Pfaff wrote:
> 	* fhandler_socket.cc (fhandler_socket::connect): Change error
> 	handling for nonblocking connects to return EALREADY when
> 	connect is called more than once for the same socket.

Ok with me.  Please apply.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin <at> cygwin.com
Red Hat, Inc.

Re: exec after seteuid

At 10:04 PM 6/7/2003 +0200, Corinna Vinschen wrote:
>I just had a look into the current login.c implementation on NetBSD.
>It is using setuid/setgid.  Actually it's using setusercontext(3)
>but with all options set which implies setuid/setgid.  Yes, using
>only seteuid/setegid in login has to be considered an error which
>just didn't matter so far.

Corinna, 

here is the patch.

It seems to work fine but it requires login.exe changes. It's
not just a question of security. ash does not setuid, while bash 
setuid(getuid()), i.e. just the opposite of what we need.

While I was looking at the most recent login.c I saw that you have
added a seteuid (priv_uid). Ideally, shouldn't it still be effective 
while calling dolastlog()? It's weird that the Berkeley code didn't do
that. There is also the issue raised by Takashi Yano on the list.

I have thrown in the little exceptions.cc quoting patch.

2003-06-09  Pierre Humblet  <pierre.humblet <at> ieee.org>

	* spawn.cc (spawn_guts): Call CreateProcess while impersonated, 
	when the real {u,g}ids and the groups are original.
	Move RevertToSelf and ImpersonateLoggedOnUser to the main line.
	* uinfo.cc (uinfo_init): Reorganize. If CreateProcess was called 
	while impersonated, preserve the uids and gids and call
 	ImpersonateLoggedOnUser. Preserve the uids and gids on Win9X.

Re: exec after seteuid

On Sun, Jun 08, 2003 at 05:32:56PM -0400, Pierre A. Humblet wrote:
> At 10:04 PM 6/7/2003 +0200, Corinna Vinschen wrote:
> >I just had a look into the current login.c implementation on NetBSD.
> >It is using setuid/setgid.  Actually it's using setusercontext(3)
> >but with all options set which implies setuid/setgid.  Yes, using
> >only seteuid/setegid in login has to be considered an error which
> >just didn't matter so far.
> 
> Corinna, 
> 
> here is the patch.
> 
> It seems to work fine but it requires login.exe changes. It's
> not just a question of security. ash does not setuid, while bash 
> setuid(getuid()), i.e. just the opposite of what we need.

I'm wondering why a shell should use setuid at all.  It's not the
task of the shell to do this, it's supposed under the environment
it gets.  So this is entirely the task of the processes which
eventually start a shell (login, rshd, sshd, etc.)

> While I was looking at the most recent login.c I saw that you have
> added a seteuid (priv_uid). Ideally, shouldn't it still be effective 
> while calling dolastlog()? It's weird that the Berkeley code didn't do

I've uploaded a new login which does that.

> that. There is also the issue raised by Takashi Yano on the list.

Which is not related to using the wrong token.  I've written something

Re: exec after seteuid

On Sun, Jun 08, 2003 at 05:32:56PM -0400, Pierre A. Humblet wrote:
> 2003-06-09  Pierre Humblet  <pierre.humblet <at> ieee.org>
> 
> 	* spawn.cc (spawn_guts): Call CreateProcess while impersonated, 
> 	when the real {u,g}ids and the groups are original.
> 	Move RevertToSelf and ImpersonateLoggedOnUser to the main line.
> 	* uinfo.cc (uinfo_init): Reorganize. If CreateProcess was called 
> 	while impersonated, preserve the uids and gids and call
>  	ImpersonateLoggedOnUser. Preserve the uids and gids on Win9X.
> 
> 	* exceptions.cc (error_start_init): Quote the pgm in the command.

Applied with some minor changes, mainly a bit more comment and a slight
simplification of uinfo_init().

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin <at> cygwin.com
Red Hat, Inc.

Re: exec after seteuid

Corinna Vinschen wrote:
> 
> > It seems to work fine but it requires login.exe changes. It's
> > not just a question of security. ash does not setuid, while bash
> > setuid(getuid()), i.e. just the opposite of what we need.
> 
> I'm wondering why a shell should use setuid at all.  It's not the
> task of the shell to do this, it's supposed under the environment
> it gets.  So this is entirely the task of the processes which
> eventually start a shell (login, rshd, sshd, etc.)

I agree 100%. If you look in bash code there is some explanation,
involving a "privileged mode" (undocumented?). I don't recall the 
details.

> > While I was looking at the most recent login.c I saw that you have
> > added a seteuid (priv_uid). Ideally, shouldn't it still be effective
> > while calling dolastlog()? It's weird that the Berkeley code didn't do
> 
> I've uploaded a new login which does that.

OK, will try later.

> > that. There is also the issue raised by Takashi Yano on the list.
> 
> Which is not related to using the wrong token.  I've written something
> on the cygwin ML.

Are you running with gid 544 by any chance?
What I saw in login.exe while stracing my patch was