5 ms·

But open(3) is a function call, so it can be hooked.

• KonradKlause 15y ago
  It's open(2). Yes, here on my x86_64 it can be hooked. But I've seen lots of setups where this was not doable. As I said it depends how the libc's wrapper is written.
  • waitwhat 15y ago
    On Linux, there's typically both an open(3) and an open(2). The former is implemented by glibc and calls the latter which is implemented by the kernel. So an app calls the open() function. This results in an unresolved symbol which the run-time linker matches up with the open() exported by glibc. glibc then does the open() syscall.
    • KonradKlause 15y ago
      open(2) is the wrapper within the libc. There is no open(3) on Linux.
      • waitwhat 15y ago
        Section 2 of the unix manual is for syscalls. Section 3 is for C library functions. http://en.wikipedia.org/wiki/Man_page#Manual_sections http://en.wikipedia.org/wiki/Man_page#Manual_sections If libc implements it, then it is by definition in section 3. EDIT: (signing out of this sub-thread)
        • KonradKlause 15y ago
          Sorry, you're just wrong. Have you ever called a system call by hand using assembly? Have you ever looked at glibc's source? Habe you ever looked at the kernel's close() syscall?
          • calloc 15y ago
            syscall number 5 you mean?
          • jrockway 15y ago
            libc implements a function called open. Its documentation appears in section 3 of the UNIX manual. Because of that, we call it open(3). Linux implements a system call called open. Its documentation appears in section 2 of the UNIX manual. Because of that, we call it open(2). From assembly, you manually call open(2). From a C program linked against libc, you typically open(3). open(3) can be hooked, because it's just a regular function. open(2) is not a function, and so cannot be hooked like a function.