On Sun, Mar 28, 2010 at 12:43:23AM +0900, J. R. Okajima wrote: > > Valerie Aurora: > > My question: How often do applications actually attempt fchown(), > > fchmod(), or utimensat() on an O_RDONLY file descriptor? Would it > > break a lot of applications if a union mount file returned EBADF or > > EPERM in this case? > > Unfortunately I don't know how often it is. > But I am afraid it will be insufficient even if you implement the error. > Do you remember the sample case I've written before? > For instance, > > fd1 = open(path, O_RDONLY); > fd2 = open(path, O_RDWR); > fchmod(fd2); > fstat(fd1, &st); > > In this case, fchmod will not return the error because fd2 is opened for > write and the file would be copied-up. And the next fstat for fd1 will > return a bogus info since fd1 still refers the file on the lower layer. > Regardless fchmod() is issued by the same process or different one, > fstat() lies. > This is the same scenario I wrote before essentially (Jul 2009). I'm working on the assumption that this is okay. Basically, an in-kernel copyup has the same effect on an application with an O_RDONLY fd as a userland copy-up to a temporary file followed by a rename() to the original name. Editors, among other applications, use this sequence all the time. If it breaks under union mount copyup, it will also break if you edit the file with vi. > Also we should take care of the file-locking. > The copyup by UnionMount will break fcntl(F_SETLK) easily in the same > scenario. But I am not sure how many applications depend upon file lock > and UnionMount copyup affect. Yeah, it isn't obvious what the expected effect would be. I'll think about it more. Thanks, -VAL -- 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
