Brian Dessent | 6 Apr 07:41 2005
Picon

[patch] dup_ent does not set dst when src is NULL


In net.cc, there are several cases where dup_ent() is used as follows:

dup_ent (servent_buf, getservbyname (name, proto), t_servent);
syscall_printf ("%p = getservbyname (%s, %s)",
    _my_tls.locals.servent_buf, name, proto);
return _my_tls.locals.servent_buf;

This presents a problem if getservbyname() returns NULL, because
dup_ent just returns NULL, it does not modify 'dst'.  This results in
the function returning the previous successful value if the
get_foo_by_bar() function returned NULL.  This seems to be applicable to
getservbyname(), getservbyport(), gethostbyaddr(), and gethostbyname().  

In the case of gethostbyname() there's also another bug in that there
will be a spurious debug_printf() about dup_ent failing if the address
simply didn't resolve.  That should probably be fixed too but I wanted
to be sure the patch stayed "trivial".

A simple testcase that demonstrates the problem:

#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <sys/socket.h>
#include <netinet/in.h>

void mygetservbyname(char *serv, char *proto)
{
  struct servent *p;
(Continue reading)

Christopher Faylor | 6 Apr 07:51 2005

Re: [patch] dup_ent does not set dst when src is NULL

On Tue, Apr 05, 2005 at 10:41:30PM -0700, Brian Dessent wrote:
>In net.cc, there are several cases where dup_ent() is used as follows:
>
>dup_ent (servent_buf, getservbyname (name, proto), t_servent);
>syscall_printf ("%p = getservbyname (%s, %s)",
>    _my_tls.locals.servent_buf, name, proto);
>return _my_tls.locals.servent_buf;
>
>This presents a problem if getservbyname() returns NULL, because
>dup_ent just returns NULL, it does not modify 'dst'.  This results in
>the function returning the previous successful value if the
>get_foo_by_bar() function returned NULL.  This seems to be applicable to
>getservbyname(), getservbyport(), gethostbyaddr(), and gethostbyname().  
>
>In the case of gethostbyname() there's also another bug in that there
>will be a spurious debug_printf() about dup_ent failing if the address
>simply didn't resolve.  That should probably be fixed too but I wanted
>to be sure the patch stayed "trivial".

Thanks for the patch, but I went out of my way to avoid freeing the
buffer when I maded changes to dup_ent a couple of weeks ago.  I don't
want to revert to doing that again, so I've just used the return value
in all cases.

cgf

Brian Dessent | 6 Apr 10:40 2005
Picon

Re: [patch] dup_ent does not set dst when src is NULL

Christopher Faylor wrote:

> Thanks for the patch, but I went out of my way to avoid freeing the
> buffer when I maded changes to dup_ent a couple of weeks ago.  I don't
> want to revert to doing that again, so I've just used the return value
> in all cases.

Thanks for taking care of that.  My original fix did more or less what
you have done, by checking the return value, but I submitted the other
way because it was much shorter and I didn't want to send anything
non-trivial.  Hmm, maybe if my printer had some ink in it I could print
out that copyright assignment form...

Brian

Corinna Vinschen | 6 Apr 10:42 2005

Re: [patch] dup_ent does not set dst when src is NULL

On Apr  6 01:40, Brian Dessent wrote:
> Christopher Faylor wrote:
> 
> > Thanks for the patch, but I went out of my way to avoid freeing the
> > buffer when I maded changes to dup_ent a couple of weeks ago.  I don't
> > want to revert to doing that again, so I've just used the return value
> > in all cases.
> 
> Thanks for taking care of that.  My original fix did more or less what
> you have done, by checking the return value, but I submitted the other
> way because it was much shorter and I didn't want to send anything
> non-trivial.  Hmm, maybe if my printer had some ink in it I could print
> out that copyright assignment form...

I'm looking forward :-)

Corinna

--

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

Kazuhiro Fujieda | 14 Apr 06:59 2005
Picon

Correct debugging output in seteuid32

I'd submit a trivial patch after a long time.

2005-04-14  Kazuhiro Fujieda  <fujieda <at> jaist.ac.jp>

	* syscalls.cc (setuid32): Correct debugging output.

Index: syscalls.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.372
diff -u -u -r1.372 syscalls.cc
--- syscalls.cc	11 Apr 2005 21:54:54 -0000	1.372
+++ syscalls.cc	14 Apr 2005 04:45:38 -0000
 <at>  <at>  -1959,7 +1959,7  <at>  <at> 
 extern "C" int
 seteuid32 (__uid32_t uid)
 {
-  debug_printf ("uid: %u myself->gid: %u", uid, myself->gid);
+  debug_printf ("uid: %u myself->uid: %u", uid, myself->uid);

   if (uid == myself->uid && !cygheap->user.groups.ischanged)
     {

____
  | AIST      Kazuhiro Fujieda <fujieda <at> jaist.ac.jp>
  | HOKURIKU  School of Information Science
o_/ 1990      Japan Advanced Institute of Science and Technology

Corinna Vinschen | 14 Apr 12:05 2005

Re: Correct debugging output in seteuid32

Hi Kazuhiro, welcome back :-)

On Apr 14 13:59, Kazuhiro Fujieda wrote:
> I'd submit a trivial patch after a long time.
> 
> 2005-04-14  Kazuhiro Fujieda  <fujieda <at> jaist.ac.jp>
> 
> 	* syscalls.cc (setuid32): Correct debugging output.

Thanks for the patch.  I'll apply it at one point, but right now I'm
debugging at this very point, so this will take some time.  Stay tuned.

Corinna

--

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

Pierre A. Humblet | 14 Apr 22:24 2005
Picon

Re: Correct debugging output in seteuid32

I can see why would one think this is a bug, but it was meant
to be that way. Having a "wrong" gid can make seteuid fail.
Perhaps we could print the new and current uids and the current
gid to cover all cases.

Pierre

At 01:59 PM 4/14/2005 +0900, Kazuhiro Fujieda wrote:
>I'd submit a trivial patch after a long time.
>
>2005-04-14  Kazuhiro Fujieda  <fujieda <at> jaist.ac.jp>
>
>	* syscalls.cc (setuid32): Correct debugging output.
>
>Index: syscalls.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
>retrieving revision 1.372
>diff -u -u -r1.372 syscalls.cc
>--- syscalls.cc	11 Apr 2005 21:54:54 -0000	1.372
>+++ syscalls.cc	14 Apr 2005 04:45:38 -0000
> <at>  <at>  -1959,7 +1959,7  <at>  <at> 
> extern "C" int
> seteuid32 (__uid32_t uid)
> {
>-  debug_printf ("uid: %u myself->gid: %u", uid, myself->gid);
>+  debug_printf ("uid: %u myself->uid: %u", uid, myself->uid);
> 
>   if (uid == myself->uid && !cygheap->user.groups.ischanged)
>     {
(Continue reading)

Corinna Vinschen | 15 Apr 10:19 2005

Re: Correct debugging output in seteuid32

On Apr 14 16:24, Pierre A. Humblet wrote:
> I can see why would one think this is a bug, but it was meant
> to be that way. Having a "wrong" gid can make seteuid fail.
> Perhaps we could print the new and current uids and the current
> gid to cover all cases.

Yep, that's how I did it already locally.  I've applied it that way.

Corinna

--

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

Christopher Faylor | 20 Apr 06:16 2005

Re: [Fwd: RE: ssh problem on Windows XP]

On Sat, Jan 22, 2005 at 03:58:45PM -0500, Bob Byrnes wrote:
>On Jan 21,  6:34pm, Corinna Vinschen wrote:
>-- Subject: [Fwd: RE: ssh problem on Windows XP]
>>
>> is there any chance that we get a fix in the next couple of weeks?
>
>I remain absolutely committed to fixing the problems that have been
>reported, but I can't say that I'll have a fix in that timeframe,
>because I have some urgent deadlines for other projects.  Maybe
>early to mid-February?

Any update on this, Bob?

cgf

Christopher Faylor | 20 Apr 06:28 2005

Re: Update of fhandler-tut.txt

On Sun, Nov 28, 2004 at 07:40:19PM +0100, Gerd Spalink wrote:
>When trying to add an experimental /dev/mixer, I found that
>the fhandler tutorial was obsolete. This patch brings it up-to-date.
>
>ChangeLog Entry:
>
>2004-11-28 Gerd Spalink <Gerd.Spalink <at> t-online.de>
>
>* fhandler-tut.txt: Update description to cygwin 1.5.13

I'm going through my email archives and see that I never applied this
patch.

That oversight has been rectified.  I've checked it in with some minor
tweaks.

Thanks for the patch and sorry for the extreme delay.

cgf


Gmane