I want to use open_excl(3) in order to open a file for exclusive writing.
I wrote:
#include <open.h>
int main(int c, char* v[]){
int fp = open_excl("my_file");
return 0;
}
Now:
gcc -Wall file.c -o out.a
And I get a fatal compiler error: open.h: No such file or directory
How come? do I have a broken path problem? Missing a link to a library?
Wrong version of gcc? I'm using 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
The open_excl is not a standard function; I don't have open.h on my Linux system. As the documentation on linux.die.net says:
open_excl opens the file filename for writing and returns the file handle. The file may not exist before the call to open_excl. The file will be created with mode 0600.
[...] open_excl relies on the O_EXCL flag to open [...]
Thus you could achieve the same with
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int open(const char *pathname, int flags, mode_t mode);
By calling it as follows:
int fd = open(filename, O_EXCL|O_CREAT|O_WRONLY, 0600);
To wrap the file descriptor into FILE * use the fdopen function:
#include <stdio.h>
FILE *fp = fdopen(fd);
Whenever you include any header file, the compiler looks for the same in standard directory if angular brackets are used #include <open.h> and in project directory if quotes are used #include "open.h".
So you can first check if you have the open.h file in the standard directory (which probably is not the case), you can download and copy the header file in your local directory and use quotes include the same.
Related
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin18.0.0
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#define _GNU_SOURCE
#define __USE_GNU 1
#include <fcntl.h>
int main()
{
int fd = open("./test.txt", O_WRONLY|O_DIRECT);
close(fd);
return 0;
}
I use clang -o out test.c and get the following result:
test.c:14:39: error: use of undeclared identifier 'O_DIRECT'
int fd = open("./test.txt", O_WRONLY|O_DIRECT);
How can I solve the problem?
Thank you.
With this snippet it is impossible to tell what you are trying to do, but in general do not use nonstandard stuff in applications intended to be portable.
The portable way to accomplish your task is probably fsync.
To sum up
For LINUX, the O_DIRECT flag has to be included. For Mac OSX, O_DIRECT is not available. Instead, fcntl(fd, F_NOCACHE, 1) looks to be the canonical solution where fd is the file descriptor of the file. For Windows, there is a flag called FILE_FLAG_NO_BUFFERING as the counterpart in Windows of O_DIRECT
Reference here
The man page of open() shows open has two definitions.
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
I was trying to make a wrap around open to add a backtrace for some debugging. The definition in fnctl.h shows it as a variable argument function
int open(const char *path, int oflag, ... );
But how can I know whether mode is present or not?
The mode argument is not needed for all open flags. For example, if opening an existing file for reading, there's no need to set the file mode flags. On the other hand, when creating a file, you need to include the mode.
See the documentation for open (or your local manual page) to see if you need to include the argument or not.
open() function -
int open (const char *filename, int flags[, mode_t mode])
mode is only used when file is created. No need when file is already present but it won't affect also in either way .
If flags include O_CREAT, there must be a third argument (mode). If not, or if the file already exists, the third argument (if supplied) will be ignored.
Since open is actually variadic, you can call it with any number of arguments (>2), but they will have no effect on the operation.
You will need to extract the mode argument using stdarg.h. The C variadic function feature does not provide any mechanism for a function to find out how many arguments it was called with, so all you can do is check the flag.
I am working out of the 2nd edition of Jon Erickson's "Hacking: The Art of Exploitation" using a VM (virutalbox) to run the LiveCD it came with (Ubuntu 7.04). In section 0x281 "File Access", the author explains accessing files through file descriptors, as well as the open() close() read() and write() functions, using an example on pages 82-84.
The code for the simplenote.c is as follows:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
void usage(char *prog_name,char *filename){
printf("Usage: %s < data to add to %s>\n",prog_name,filename);
exit(0);
}
void fatal(char *);
void *ec_malloc(unsigned int );
int main(int argc,char *argv[]){
int fd; //file descriptor
char *buffer,*datafile;
buffer = (char *)ec_malloc(100);
datafile = (char *)ec_malloc(20);
strcpy(datafile,"/tmp/notes");
if(argc < 2)
usage(argv[0],datafile);
strcpy(buffer,argv[1]);
printf("[DEBUG] buffer # %p:\'%s'\n",buffer,buffer);
printf("[DEBUG] datafile # %p:\'%s'\n",datafile,datafile);
strncat(buffer,"\n",1);//Add a newline on the end.
fd = open(datafile,O_WRONLY|O_CREAT|O_APPEND,S_IRUSR|S_IWUSR);
if(fd == -1)
fatal("in main() while opening file");
printf("[DEBUG] file descriptor is %d\n",fd);
//Writing data
if(write(fd,buffer,strlen(buffer)) == -1)
fatal("in main() while writing buffer to file");
//Closing file
if(close(fd) == -1)
fatal("in main() while closing file");
printf("Note has been saved.\n");
free(buffer);
free(datafile);
}
//A function to display an error message and then exit
void fatal(char *message){
char error_message[100];
strcpy(error_message,"[!!]Fatal Error");
strncat(error_message,message,83);
perror(error_message);
exit(-1);
}
//An error-checked malloc() wrapper function
void *ec_malloc(unsigned int size){
void *ptr;
ptr = malloc(size);
if(ptr == NULL)
fatal("in ec_malloc() on memory allocation");
return ptr;
}
However, when I type the following instructions stated in the book into my terminal window, it returns the following error message:
reader#hacking:~/booksrc $ gcc -o simplenote simplenote.c
In file included from /usr/include/sys/stat.h:105, from simplenote.c:6:
/usr/include/bits/stat.h:70: error: field 'st_atim' has incomplete type
/usr/include/bits/stat.h:71: error: field 'st_mtim' has incomplete type
/usr/include/bits/stat.h:72: error: field 'st_ctim' has incomplete type
simplenote.c: In function 'main':
simplenote.c:35: error: 'O-WRONLY' undeclared (first use in this function)
simplenote.c:35: error: (Each undeclared identifier is reported only once
simplenote.c:35: error: for each function it appears in.)
simplenote.c:35: error: 'O_CREAT' undeclared (first use in this function)
simplenote.c:35: error: 'O_APPEND' undeclared (first use in this function)
Here is sys/stat.h line 105:
#include <bits/stat.h>
And here is bits/stat.h lines 63-83:
#ifdef __USE_MISC
/* Nanosecond resolution timestamps are stored in a format
equivalent to 'struct timespec'. This is the type used
whenever possible but the Unix namespace rules do not allow the
identifier 'timespec' to appear in the <sys/stat.h> header.
Therefore we have to handle the use of this header in strictly
standard-compliant sources special. */
struct timespec st_atim; /* Time of last access. */
struct timespec st_mtim; /* Time of last modification. */
struct timespec st_ctim; /* Time of last status change. */
# define st_atime st_atim.tv_sec /* Backward compatibility */
# define st_mtime st_mtim.tv_sec
# define st_ctime st_ctim.tv_sec
#else
__time_t st_atime; /* Time of last access. */
unsigned long int st_atimensec; /* Nscecs of last access. */
__time_t st_mtime; /* Time of last modification. */
unsigned long int st_mtimensec; /* Nsecs of last modification. */
__time_t st_ctime; /* Time of last status change. */
unsigned long int st_ctimensec; /* Nsecs of last status change. */
#endif
I suppose this might be of some use for the first set of issues:
C++ system file bits/stat.h suddenly breaks with "error: field ‘st_atim’ has incomplete type"
/usr/include/time.h
cat time.h
doesn't do anything in my terminal window.
And here is the simplenote.c main function lines 1-6, 34-35:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
// Opening the file
fd = open(datafile, O_WRONLY|O_CREAT|O_APPEND, S_IRUSR|S_IWUSR);
I'm guessing the open function problems stem from fcntl.h ?
I seem to keep running into issues because of faulty code the author provided. I don't want to constantly depend on the stackoverflow community for help, so what suggestions do you have for a novice about examining and fixing these problems in the future?
Thanks.
Transferring a selection of comments into a semi-coherent answer.
You should probably explicitly enable POSIX definitions. Add -D_XOPEN_SOURCE=700 to the command line, or #define _XOPEN_SOURCE 700 before the first #include and see if that solves anything. You should not be running into the problem though; the header should be self-contained.
Oh, but Ubuntu 7.04 is archaic…you may need to use 600 instead of 700. When was it released (when was the book published)? If it was 2009 or before, you probably need the older version (600). It's still surprising that you're seeing the error. The command line you specify doesn't contain the options that normally cause trouble (-ansi -pedantic, for example, or -std=c99 -pedantic). You could try using -std=gnu99 too; it might work better.
You had a similar problem recently (gcc -o stdlib.h syntax error c Hacking the Art of Exploitation). Did you get that resolved? It sounds as if the compilation system on the Live CD is not self-coherent, or the way you're able to use it means that it is not behaving self-coherently. Are you sure the compilation system works? It appears to be semi-defunct. Is it using the wrong headers, somehow?
I was able to resolve the previous problem by inserting #include <stdint.h> before #include <stdlib.h>
I will try the -D_XOPEN_SOURCE=600 and get back to you. Something must be wrong with the compilation system.
Well, you might need to include <time.h> (or possibly <sys/time.h>) before <sys/stat.h>, but the <sys/stat.h> header is broken if that works. And the <stdlib.h> header is broken if you have to include <stdint.h> before including it. I suppose Ubuntu 7.04 could be so old that you're supposed to #include <sys/types.h> before many of these headers, but that's still not an excuse for <stdlib.h>; that should be self-contained. POSIX 1997 required #include <sys/types.h> before <sys/stat.h>; POSIX 2004 did not. And I don't think Ubuntu 7.04 is quite that old.
Note, though, that the st_atim member is new; it was added to POSIX 2008 (and hence is in POSIX 2013). It was just st_atime before (and st_atime is now a macro for st_atim.tv_sec).
Including the -D_XOPEN_SOURCE=600 dealt with the bits stat issue. Ubuntu 7.04 was released in 2007 and the 2nd edition of the book that I am using came out in 2008. Also, not sure if this is of use, but in another previous example that included both <stdio.h> and <string.h> (as opposed to only <stdio.h>), the code would run fine without any intervention.
Interesting…it is going to make life interesting for you, in a way that life should not need to be interesting. (Chinese curses like "May you live in interesting times" spring to mind.) Use the -DXOPEN_SOURCE=600 option in all your compilations and keep your fingers crossed; that may well resolve most of your problems. Consider using -std=gnu99 as well, or instead. With luck, either or both of those should get you around most problems.
In case someone else is having the same issue with this book, I downloaded the iso file from hacking-live-1.0.iso.
Created a bootable usb and all works just fine without corrupted headers or anything.
When I attempt to overwrite an existing file, I get a "permission denied" error.
I noticed that the file which is created has the "Read-only" attribute set. When I manually unset this I can then overwrite the file. Is there some flag I can pass to open() which will automatically unset this when I create a file?
Below is a bare bones example which illustrates the problem. The first run works, but the second produces the "permission denied" error.
Thanks,
Zach (New to MingW/Windows 7)
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <fcntl.h>
#include <errno.h>
int main(int argc, char ** argv) {
int fid;
double data = 12.0;
if ( (fid = open("junk.data", O_WRONLY | O_CREAT | O_BINARY)) == -1 ) {
printf("ERROR opening.\n\terror is:%s\n", strerror(errno));
return 1;
}
write(fid, &data, sizeof(double));
close(fid);
return 0;
}
I tried both 0644 and S_IRUSR | S_IWUSR (with sys/stat.h included) and either works.
Make sure that you actually add it as third argument of open, instead as new term into the surrounding parentheses (as happened for me first, and compiles just fine)
open has a three-parameter variant:
int open(const char *pathname, int flags, mode_t mode);
That third parameter allows you to specify the mode bits on Unix-type systems, but should be enough to set minimal r/w permissions on windows. (Check out the man page for details.)
I'm trying to use the nftw to process some files under a directory
#include <ftw.h>
#include <stdio.h>
int wrapper(const char * fpath, const struct stat *sb, int typeflag, struct FTW *ftwbuf) {
printf("File %d\n", ftwbuf->base);
return(0);
}
int main(int argc, char ** argv) {
const char *name;
int flags = 0;
name = argv[1];
nftw(name, wrapper, 20, flags);
return 0;
}
When I'm compiling (gcc kconfig_parser.c -o parser) , I've got this warning and this error..
kconfig_parser.c:5: warning: ‘struct FTW’ declared inside parameter list
kconfig_parser.c:5: warning: its scope is only this definition or declaration, which is probably not what you want
kconfig_parser.c: In function ‘wrapper’:
kconfig_parser.c:6: error: dereferencing pointer to incomplete type
I've checked the definition of the struct and the prototype of the callback, and some examples, it should be fine... What am I doing wrong ? (I've removed almost everything of my code to clear it)...
thanks
Linux, for some reason, still uses SUSv1 for this API, where nftw() is still considered an extension.
From the Linux manual page, the include has to be:
#define _XOPEN_SOURCE 500
#include <ftw.h>
Hmm. Your code works for me. Check your include paths, maybe? Though this is a system header, so it should be pretty hard to miss this. Or were you accidentally compiling a version that didn't have the #include <ftw.h> line?
$ gcc -o ftw ftw.c
$ ./ftw my-directory
File 10
File 11
File 16
File 16
File 16
File 16
File 16
... etc ...
edit: The test above was done on Mac OS X. In a (now deleted) comment the OP mentioned he was on Debian, for which the man page mentions that #define _XOPEN_SOURCE 500 is necessary, as Juliano points out.
On a CentOs versions the header file didn't use "#define _XOPEN_SOURCE 500"
i had to do this below,
#define __USE_XOPEN_EXTENDED 1
#include <ftw.h>
On Ubuntu 18.04, this is what seems to work now (similar to CentOS as mentioned by JohnMeg).
#define __USE_XOPEN_EXTENDED 1
#include <ftw.h>