GNU bug report logs - #30176
readlinkat and _FORTIFY_SOURCE on Cygwin

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30176 in the body.
You can then email your comments to 30176 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: readlinkat and _FORTIFY_SOURCE on Cygwin
Date: Fri, 19 Jan 2018 15:46:39 -0500

The next release of Cygwin (2.10.0), expected within the next few weeks, 
is going to have a new implementation of _FORTIFY_SOURCE guards for many 
functions, including readlinkat.  The implementation is based on that of 
NetBSD and has the effect of adding code that looks essentially as 
follows after preprocessing:

ssize_t
__ssp_real_readlinkat (int __dirfd1, const char *__path,
                       char *__buf, size_t __len)
  __asm__("readlinkat");

extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
ssize_t
readlinkat (int __dirfd1, const char *__path, char *__buf,
            size_t __len)
  __asm__("__ssp_protected_readlinkat");

extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
ssize_t
readlinkat (int __dirfd1, const char *__path, char *__buf,
            size_t __len)
{
  if (__builtin_object_size(__buf, 2 > 1) != (size_t)-1
      && __len > __builtin_object_size(__buf, 2 > 1))
    __chk_fail();
  return __ssp_real_readlinkat (__dirfd1, __path, __buf, __len);
}

The occurrence of this code in fileio.c, combined with the use of a 
pointer to readlinkat in the definition of emacs_readlinkat, leads to an 
"undefined reference to `__ssp_protected_readlinkat'" linking error.

I'd appreciate some advice on how to fix this.  I can think of three 
possibilities, but maybe there's something better:

1. Add "#define _FORTIFY_SOURCE 0' at the top of fileio.c (Cygwin only).

2. Pretend like Cygwin doesn't have readlinkat.  Then gnulib will create 
its own definition, which will be found by the linker in libegnu.a.

3. Ask gnulib to come up with a fix.

Thanks in advance for any advice.

Ken

Message #8 received at 30176 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>, 30176 <at> debbugs.gnu.org
Subject: Re: bug#30176: readlinkat and _FORTIFY_SOURCE on Cygwin
Date: Fri, 19 Jan 2018 15:25:02 -0800

On 01/19/2018 12:46 PM, Ken Brown wrote:
> I can think of three possibilities, but maybe there's something better:
>
> 1. Add "#define _FORTIFY_SOURCE 0' at the top of fileio.c (Cygwin only).
>
> 2. Pretend like Cygwin doesn't have readlinkat.  Then gnulib will 
> create its own definition, which will be found by the linker in 
> libegnu.a.
>
> 3. Ask gnulib to come up with a fix.

(2) is presumably not good, since the substitute readlinkat will have to 
execute several system calls and this will be problematic.

(1) should work but kind of misses the point of fortification.

I don't know what would be involved in (3).

How about a better option, like this:

4. Fix Cygwin readlinkat so that it can be used as a function pointer 
even when _FORTIFY_SOURCE is used.

Why not do what glibc does with readlinkat? It fortifies readlinkat, and 
doesn't run into this problem.

Message #13 received at 30176-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 30176-done <at> debbugs.gnu.org
Subject: Re: bug#30176: readlinkat and _FORTIFY_SOURCE on Cygwin
Date: Sat, 20 Jan 2018 07:30:26 -0500

On 1/19/2018 6:25 PM, Paul Eggert wrote:
> 4. Fix Cygwin readlinkat so that it can be used as a function pointer 
> even when _FORTIFY_SOURCE is used.
> 
> Why not do what glibc does with readlinkat? It fortifies readlinkat, and 
> doesn't run into this problem.

Sorry, that was stupid of me.  I don't know why I was thinking that this 
was an Emacs issue.

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.