2

I recently tried to compile vsftpd 3.0.0 but it fails due the following compile error:

gcc -c seccompsandbox.c -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wall -W -               Wshadow -Werror -Wformat-security -D_FORTIFY_SOURCE=2  -idirafter dummyinc
seccompsandbox.c:63: error: ‘O_DIRECTORY’ undeclared here (not in a function)
seccompsandbox.c:63: error: ‘O_CLOEXEC’ undeclared here (not in a function)
make: *** [seccompsandbox.o] Error 1

As I'm not very familar with the source and the environment I have no idea how to fix this. I imagine that it has something to do with the new seccomp filter sandbox. A Search on google showed me that the error is reproducible but no solution was submitted.

My linux kernel version is 2.6.32-5-amd64 and I'm using gcc version 4.4.5 (Debian 4.4.5-8)

Any ideas welcome. (If you need additional information's don't hesitate to ask)

Alfred Huang
  • 17,654
  • 32
  • 118
  • 189
Mythli
  • 5,995
  • 2
  • 24
  • 31

2 Answers2

4

At least on Debian O_DIRECTORY and O_CLOEXEC are defined only if _GNU_SOURCE is defined.

Although _GNU_SOURCE is set for certain modules in the current vsftp release it is not set generally.

As a work around you might use the following patch:

diff -Naur vsftpd-3.0.0.orig/seccompsandbox.c vsftpd-3.0.0/seccompsandbox.c
--- vsftpd-3.0.0.orig/seccompsandbox.c       2012-04-05 00:41:51.000000000 +0200
+++ vsftpd-3.0.0/seccompsandbox.c  2012-06-30 15:25:52.000000000 +0200
@@ -11,7 +11,7 @@
 #include "seccompsandbox.h"

 #if defined(__linux__) && defined(__x86_64__)
-
+#define _GNU_SOURCE
 #include "session.h"
 #include "sysutil.h"
 #include "tunables.h

Disclaimer: Applying this patch makes the current vsftp release compile, I have now clue wether the created binaries work correctly or not.

alk
  • 69,737
  • 10
  • 105
  • 255
  • This works for me but as I will use vsftpd on a live server it seems like I have to dig further into this. However, thank you. – Mythli Jul 04 '12 at 18:22
  • You are welcome. What is the platform you are running your live servers on? – alk Jul 04 '12 at 19:16
  • My live server is running debian (the exact version is in my question). – Mythli Jul 06 '12 at 14:22
  • The bug has been reported to bugs.debian.org as #680554. @Mythli – alk Jul 07 '12 at 11:32
  • On an old Ubuntu 9.10 system I have, they're defined if `__USE_GNU` is set. On a Ubuntu 12.10 system they're defined if `__USE_XOPEN2K8` is set. – Dennis Williamson Sep 01 '13 at 15:48
0

I'm using SLES 11 sp1 64bit, kernel 2.6.32, gcc ver 4.3.4; changing or removing FORTIFY_SOURCE made no difference, get same error. I'm not a c programmer - the flags O_DIRECTORY and O_CLOEXEC are in seccompsandbox.c:

static const int kOpenFlags =
    O_CREAT|O_EXCL|O_APPEND|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_LARGEFILE;

It compiles if you remove them but that really fills me with confidence....

The vrf_findlibs.sh is also broken, I had to rejig the script so it found a 64bit version of libcap first or it keeps selecting the 32bit copy (the -lcap doesn't work either, says it isn't found):

# Look for libcap (capabilities)
if locate_library /lib64/libcap.so; then
  echo "/lib64/libcap.so.2";
elif locate_library /lib/libcap.so.1; then
  echo "/lib/libcap.so.1";
elif locate_library /lib/libcap.so.2; then
  echo "/lib/libcap.so.2";
else
  locate_library /usr/lib/libcap.so && echo "-lcap";
  locate_library /lib/libcap.so && echo "-lcap";
  locate_library /lib64/libcap.so && echo "-lcap";
fi
Phil Crooker
  • 1