| |||||||||||||
|
| |||||||||||||
Some Linux kernel security vulnerabilitiesSome Linux kernel security vulnerabilitiesPosted Nov 10, 2004 23:57 UTC (Wed) by jwb (guest, #15467)In reply to: Some Linux kernel security vulnerabilities by NAR Parent article: Some Linux kernel security vulnerabilities
I agree that this is a common trap in C programming. Instead of:
return_value_or_status = function(args);
I prefer to see:
status = function(&return_value, args);
Which also has the advantage that more than one value can be returned. read(2), in particular, is almost impossible to use, and this goes for all Unix across all time, not just for Linux. The conflation of the file position and the status of the result is very confusing. And, if read returns -1, there's absolutely nothing you can do about it without closing the fd and starting from scratch (because the file position becomes undefined).
Okay, the whole Unix API is hard to use, and so is C ;)
(Log in to post comments)
file position after error from read() Posted Nov 11, 2004 0:39 UTC (Thu) by jreiser (subscriber, #11027) [Link] And, if read returns -1, there's absolutely nothing you can do about it without closing the fd and starting from scratch (because the file position becomes undefined).In most cases (EAGAIN, EISDIR, EBADF, EINVAL, EFAULT, and non-POSIX EINTR) you can interpret errno and resume. Only for EIO or for POSIX EINTR is there the possibility of undefined position, and some of that is due to POSIX allowing the kernel a choice of what to do with EINTR. As long as the fd is seekable and the error condition is transient, then the program can recover by seeking to any previous known-good position [the program must track such positions] and resuming. Also, if the fd is seekable then the current position can be determined using lseek(fd, (off_t)0, SEEK_CUR). All in all, that is a long way from being forced to close the fd and start from scratch. In practice, read() on a disk file is very well behaved, especially for reads of 1 sector. [Reading from a socket is different.]
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 3:58 UTC (Thu) by uriel (guest, #20754) [Link] As usual, this was fixed in Plan 9 many years ago.
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 14:42 UTC (Thu) by melauer (guest, #2438) [Link] > As usual, this was fixed in Plan 9 many years ago.
The pencil and paper which I use as a word processor doesn't have these vulnerabilities either. Now that's secure design!
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 16:06 UTC (Thu) by smurf (subscriber, #17840) [Link] > As usual, this was fixed in Plan 9 many years ago.
I don't know about the in-kernel stuff, but Plan9's basic read() system call doesn't differ much from common Unix semantics -- including short reads -- and thus I kindof doubt that the inside is different.
|
|
||||||||||||