On Mon 14-04-08 13:06:13, Lennart Sorensen wrote: > On Mon, Apr 14, 2008 at 06:53:54PM +0200, Jan Kara wrote: > > Well, but imagine you have a file /proc/my_secret_file from which you > > are able to read from position A:a and B:b but not from position > > A:b. Concievably, checks for the file position could be bypassed because of > > this race... I know this is kind of dumb example but I can imagine someone > > can eventually find something like this. So I guess one spin lock/unlock > > pair is a price worth paying in the callpath which is quite long anyway. > > But only two threads within the process can read from the filehandle and > hence the process would be doing locking. And external attacker can't Why would it be doing locking? If some nasty user runs the process, he *wants* his two threads to race as much as possible and trigger the race. And then use corrupted f_pos. > break the internal locking of the process between the threads, and even > if you do open the file in /proc that the process is using, being and > external process you would have your own file handle and hence your own > file position since you aren't part of that process. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
